卷1：第18章 SnowFlock

云計算提供了一個令人難以置信的計算平臺。用戶通過點擊幾下用戶可以以每小時不到10美分的價格租用在云中的服務器，節(jié)約了使用物理設備的所有相關時間，精力和前期成本。云供應商提供虛擬機（虛擬機），而不是物理計算機來實現(xiàn)低成本運營。云計算的關鍵是虛擬化軟件，被稱為虛擬機監(jiān)視器（虛擬機M），用來模擬一臺物理機器。用戶們非常安全地使用相互的客戶虛擬機，而沒有意識到他們通常與許多人共享物理機（“主機”）。

18.1 SnowFlock簡介

云計算是敏捷組織的福音。對于使用物理服務器而言，用戶需要焦急地等待著緩慢的審批流程，批準購買服務器，下訂單，直至服務器出貨，然后安裝和配置操作系統(tǒng)（OS）和應用程序組。而云用戶不需要等待數(shù)周的購買流程，只專注過程控制，并可以在幾分鐘內創(chuàng)建一個新的獨立服務器。

不幸的是，云服務器很少是獨立的。在快速實例化和按次使用模式的帶動下，云服務器通常是在配置相似的服務器可變池中的一個實例，能夠執(zhí)行動態(tài)和可擴展的并行計算，數(shù)據(jù)挖掘，或web等任務。因為需要多次從相同的靜態(tài)模板中啟動新的實例，商業(yè)云還不能兌現(xiàn)真正的按需計算的承諾。服務器實例化后，云用戶仍然必須管理群集成員及通過增加新的服務器來調整。

SnowFlock通過虛擬機克隆技術解決了這些問題，這就是我們所提出的云API調用。應用程序代碼經(jīng)常通過一個系統(tǒng)調用接口調用OS服務，它現(xiàn)在也可以以同樣的方式通過類似的接口調用云服務。通過SnowFlock的虛擬機克隆技術，我們可以將資源分配，集群管理和應用程序邏輯可編程等諸多方面交織在一起，并作為一個單一的邏輯操作。

根據(jù)父虛擬機,虛擬機克隆技術實例化了云服務器的多個完全相同副本。從邏輯上講，克隆的虛擬機繼承了其父節(jié)點的所有狀態(tài)，包括操作系統(tǒng)和應用程序級緩存。此外，虛擬機的克隆都將被自動添加到一個內部私有網(wǎng)絡中，從而有效地加入了這個動態(tài)可擴展的群集。新的計算資源，被封裝為相同的虛擬機，從而可以按需動態(tài)創(chuàng)建。

就實際使用而已，虛擬機克隆技術是可用，高效，而且快速的。在這一章中，我們將描述SnowFlock中對虛擬機克隆技術的實現(xiàn)，包括如何有效地在多個不同的編程模型和框架實現(xiàn)克隆， 如何在應用程序運行時使服務器的開銷最少，以及如何在5秒或更少的時間內來創(chuàng)造幾十個新的虛擬機，等等。

SnowFlock非常靈活，能夠使用C， C + +，Python和Java的API來實現(xiàn)虛擬機克隆的程序控制。我們已經(jīng)成功地將SnowFlock移植到多個不同系統(tǒng)的原型實現(xiàn)中。在并行計算中，我們通過精確克隆技術有效地分擔了在許多物理主機的負載，并取得了良好的效果。對于在一個專用的服務器集群上運行的使用了消息傳遞接口（MPI）的多個并行應用，需要修改MPI的啟動管理器，從而提供了良好的性能和更少的開銷，并且不需要修改應用就能夠在每個新的克隆集群上運行。最后，在一些完全不同的應用案例中，我們使用SnowFlock來提高彈性服務器的效率和性能。今天，基于云服務的新業(yè)務一般需要啟動新的服務器。而通過克隆運行中的虛擬機，SnowFlock帶來了新的服務器功能。由于克隆的虛擬機繼承他們的父節(jié)點的熱緩沖區(qū)，從而使性能迅速達到峰值，使上線速度快了20倍。

18.2 虛擬機克隆

顧名思義，虛擬機克隆與父虛擬機幾乎是相同的。實際上，還是有一些輕微且必要的差異的，例如避免MAC地址沖突等問題，但我們會稍后討論。創(chuàng)建一個整個本地磁盤和內存狀態(tài)的虛擬機克隆是必須的，這也是我們第一個主要的設計權衡：應該如何按需復制前端的狀態(tài)？

實現(xiàn)虛擬機克隆最簡單的方式是采用標準的虛擬機“遷移”能力。通常情況下，遷移是指將運行中的虛擬機服務移動到不同的主機上，例如如當主機超載或需要維修的情況下。但是，因為虛擬機是純粹的軟件，所以可以被封裝在一個數(shù)據(jù)文件，然后將其復制到一個新的主機上，在短暫中斷后重新執(zhí)行。要做到這一點，現(xiàn)有的VMMS要包含一個“檢查點”來創(chuàng)建文件，該文件包括本地文件系統(tǒng)，內存映像，虛擬CPU（VCPU）寄存器等等。在遷移過程中，新啟動的副本替換原來的虛擬機，但這個過程是可以改變的，例如離開原來的虛擬機運行時可以產(chǎn)生一個虛擬機克隆。在這種所謂的“渴望”進程中，因為整個虛擬機處于狀態(tài)轉移前的執(zhí)行狀態(tài)，所以整個虛擬機提供了最好的初始性能。這種復制的缺點是在開始執(zhí)行前必須費力地復制整個虛擬機，這嚴重地影響了實例化的過程。

SnowFlock采用了另一種極端方式，即是延遲狀態(tài)復制。不再復制全部虛擬機，而是復制虛擬機轉移時所需得重要數(shù)據(jù)，在虛擬機轉移后，SnowFlock在復制克隆中所需的其他數(shù)據(jù)。這有兩個好處，首先，它最大限度地減少了工作量，盡可能實例化延遲加載。其次，它只復 制真正使用的狀態(tài)數(shù)據(jù)，實際上是提高了虛擬機克隆的效率。當然，這樣做的好處取決于克隆的行為，但少量的應用程序需要訪問內存和在本地文件系統(tǒng)的每個文件的每一頁時就效果不大了。

然而，延時復制的好處不是免費的。由于狀態(tài)轉移被推遲到最后，需要在狀態(tài)到達時，才能繼續(xù)執(zhí)行克隆。在時間共享工作站內將內存交換到磁盤，而并行的應用程序從高延遲的數(shù)據(jù)源獲取狀態(tài)可能被阻塞。在SnowFlock的用例中，這些阻塞降低了克隆的性能，其嚴重程度取決于應用程序。對于高性能計算應用，我們已經(jīng)發(fā)現(xiàn)這種退化的影響不大，但可能會首先克隆的數(shù)據(jù)庫服務器性能。應當指出的是，這是一個瞬態(tài)影響：在幾分鐘之內，大多數(shù)必要的狀態(tài)已被轉移且性能父節(jié)點匹配。

順便說一句，如果你熟悉虛擬機，你可能考慮在這里使用實時遷移的優(yōu)化。實時遷移的優(yōu)化，可以縮短原始虛擬機的暫停和恢復執(zhí)行新副本之間的間隔。要做到這一點，虛擬機監(jiān)視器（VMM）需要在父節(jié)點仍在運行時預拷貝它的狀態(tài)，從而使只有最近更改過的頁才遷移。這項技術不會影響之間的遷移要求和副本開始執(zhí)行的時間間隔，因此不會降低虛擬機克隆的實例化延遲。

18.3 SnowFlock的實現(xiàn)方法

SnowFlock實現(xiàn)虛擬機克隆被稱為“虛擬機fork”，這就像標準的Unix系統(tǒng)調用fork一樣，但有幾個重要的差異。第一，系統(tǒng)調用fork是復制一個單一的進程，虛擬機fork重復整個虛擬機，包括所有的內存，所有的進程和虛擬設備，以及本地文件系統(tǒng)。第二，系統(tǒng)調用fork是產(chǎn)生在同一物理主機上運行的單個副本，虛擬機fork可以同時產(chǎn)生多個并行備份。最后，虛擬機可以被復制到不同的物理服務器，讓你迅速提高云服務的需要。

以下是SnowFlock中的核心概念：

? 虛擬化：虛擬機封裝了計算環(huán)境，使機器復制和云服務成為可能。

? 延遲傳播：直到需要的時候才復制虛擬機的狀態(tài)，虛擬機克隆在幾秒鐘內生成。

? 組播：諸多的虛擬機克隆有著類似的狀態(tài)需求。通過多播，幾十個虛擬機克隆可以盡快執(zhí)行。

? 頁故障：當一個克隆使用了無效的內存空間，這一故障將觸發(fā)一個請求到父節(jié)點，直到所需的內存頁可用了，才繼續(xù)執(zhí)行克隆操作。

? 寫復制（COW）：在虛擬機克隆生成前，父虛擬機先保留一個當前內存和磁盤頁的副本，在保留虛擬機克隆所需的狀態(tài)同時可以繼續(xù)運行。

我們使用Xen虛擬化系統(tǒng)來實現(xiàn)的SnowFlock，所以弄清一些Xen的專用術語是非常有用的。在Xen環(huán)境中，VMM被稱為虛擬機管理程序，虛擬機被稱為域。在每臺物理機（主機）說，是一個特權域，稱為“域0（dom0），每個特權域能夠完整地訪問主機及其物理設備。如果虛擬機被用來控制額外的“訪問者”或“用戶”，則被稱為“域U”（domU）。

廣義而言，SnowFlock包括一套修改了的Xen虛擬機管理程序（使其在無效資源被訪問時能夠順利恢復），一組運行在dom0上的支持進程和系統(tǒng)服務包括無效虛擬機狀態(tài)的合作遷移，以及一些虛擬機克隆中OS修改，由六個主要組成部分 。

? 虛擬機描述器：這個小對象是虛擬機克隆的抽象描述，描述了需要開始執(zhí)行的虛擬機基本框架。它沒有需要執(zhí)行任何實際工作血肉。

? 組播分發(fā)系統(tǒng)（mcdist）：這是父節(jié)點系統(tǒng)，能夠同時向所有克隆有效地發(fā)布虛擬機的狀態(tài)信息。

? 內存服務器進程：父節(jié)點服務器進程中維護了父節(jié)點狀態(tài)的多個副本，并使其根據(jù)需求通過多播mcdist發(fā)布給所有克隆。

? Memtap進程：一個虛擬機克隆端的進程，與內存服務器通信請求那些克隆所需要但又缺失的內存頁。

? 克隆提示器：運行在克隆內的guest內核，通過為VMM提供線索來按需減少虛擬機狀態(tài)的遷移。盡管是可選的，卻是高效的。

? 控制棧：運行在每個物理主機上得守護進程,協(xié)調其他組件以及管理SnowFlock的父節(jié)點和虛擬機克隆。

圖18.1：SnowFlock 虛擬機復制架構

如圖所示，圖18.1描繪克隆一個虛擬機的過程，主要有四個主要步驟：（1）暫停父虛擬機并產(chǎn)生一個虛擬機描述器;（2）將虛擬機描述器分發(fā)到所有目標主機（3）克隆初始化;（4）按需加載狀態(tài)。該圖還描述了使用mcdist 進行組播分發(fā)的方法，并取通過訪問啟示避免相關問題 。

如果你有興趣嘗試SnowFlock，這里有兩種方法。多倫多大學SnowFlock研究項目組提供了文文檔和開放的源代碼1， . 如果您愿意采用一個工業(yè)化的版本，可以從GridCentric公司2 獲得一個免費的非商業(yè)許可證.由于SnowFlock包括hypervisor的修改和dom0的訪問的，所以安裝SnowFlock需要對主機的訪問權限。出于這個原因，你需要使用自己的硬件，將不能使用如亞馬遜的EC2云環(huán)境等商業(yè)云服務。

在接下來的幾節(jié)中，我們將描述瞬時實現(xiàn)和高效克隆的協(xié)同工作。我們將所以地內容結合在一起，如圖18.2所示 。

圖18.2：SnowFlock的的軟件組件

18.4 構建虛擬機描述器

SnowFlock的設計關鍵是決定推遲虛擬機的狀態(tài)復制到一個延遲運行操作。換句話說，復制虛擬機的內存是后期綁定操作，從而為優(yōu)化的許多機會。

第一步的設計決定是生成虛擬機狀態(tài)的架構描述器。這是將用于創(chuàng)建克隆虛擬機的種子。它包含了創(chuàng)建一個虛擬機的最低必要條件，使其可以被調度。顧名思義，這一必要條件是由架構規(guī)范所需要的數(shù)據(jù)結構組成。在SnowFlock中，該架構是Intel x86處理器和Xen的結合。因此，架構的描述包含數(shù)據(jù)結構，如頁表，虛擬寄存器，設備元數(shù)據(jù)，wallclock時間戳等.我們推薦有興趣的讀者可以參考[LCWB +11 ]架構描述器的內容來深入理解。

一個架構描述器有三個重要的屬性：首先，它可以在短時間內創(chuàng)建200毫秒的情況并不少見。其次，它是小的，通常是小于原虛擬機的內存分配三個數(shù)量級（1 MB為1 GB的虛擬機）。第三，從一個描述符創(chuàng)建克隆虛擬機可以在一秒鐘之內（通常為800毫秒）。

當然，主要的時間開銷是從描述他們的記憶狀態(tài)創(chuàng)建克隆虛擬機全部的時間。以下各節(jié)我們說明如何解決這個問題，如何利用優(yōu)勢，并提出優(yōu)化的機會。

18.5父節(jié)點組件

一旦被克隆的虛擬機成為一個父節(jié)點, 就和所有其他父節(jié)點一樣，它需要為子節(jié)點提供克隆服務。父節(jié)點是通過維護一套內存和磁盤狀態(tài)，克隆的集會,為克隆虛擬機提供按需服務。

18.5.1 memserver進程

當創(chuàng)建架構描述器的時候，虛擬機將在進程中停止。這保證了虛擬機的內存狀態(tài)穩(wěn)定;在暫停虛擬機并執(zhí)行調度或取消調度前，內部OS驅動程序處于停頓狀態(tài)，從克隆可以重新連接到外部網(wǎng)絡。我們采取這種靜止狀態(tài)的優(yōu)勢來創(chuàng)建一個“內存服務器”即memserver。

內存服務器將提供克隆虛擬機所需的所有父節(jié)點內存數(shù)據(jù)。內存轉移是以x86的內存頁（4字節(jié)）為粒度單位的。最簡單的形式是內存服務器等待來自克隆的內存頁請求，在一個時間上為一個克隆提供一個內存頁的轉移。

然而，這些需要轉移的內存在父虛擬機中需要繼續(xù)使用并執(zhí)行。如果我們允許父節(jié)點去修改這個內存，那將會以損壞的內存內容克隆虛擬機：內存供應將是從不同的克隆點完成的，使克隆容易混淆。以破解內核的詞匯來說，這是一個堆棧信息跟蹤的問題。

為了克服這個問題，采用經(jīng)典的操作系統(tǒng)概念來救援：Copy-on-Write, 即CoW memory.。通過輔助的Xen hypervisor，我們可以移除父虛擬機的所有內存頁寫入權限。當父節(jié)點試圖修改一個內存頁，將觸發(fā)硬件內存頁錯誤。Xen通過頁面的副本知道這種情況發(fā)生的原因。父虛擬機允許寫入到原來的頁面，并繼續(xù)執(zhí)行，而被告知使用原來的副本，這就是保持只讀的內存服務器。在這種方式下，被克隆的內存狀態(tài)仍然凍結，且不混淆，而父節(jié)點能夠繼續(xù)執(zhí)行。CoW的開銷是最小的：Linux使用了類似的機制，如創(chuàng)建一個新的進程。

18.5.2 Multicast與Mcdist

克隆通常存在被稱為“命運的決定”的問題。 我們希望創(chuàng)建克隆是為了一個單一的目的：例如，相對于Y調整一個數(shù)據(jù)庫的DNA中X鏈。此外，我們期望要創(chuàng)建一套克隆，使所有的兄弟姐妹做的一樣，也許對數(shù)據(jù)庫的不同部分對準相同的X鏈，或調整不同的鏈對準Y鏈，從而明確地表現(xiàn)為大量內存訪問的時間局部性：他們將使用相同的代碼和大部分常見的數(shù)據(jù)。

我們利用時間局部性，為SnowFlock量身定制了自己的組播分發(fā)系統(tǒng)—— mcdist。mcdist使用IP組播，同時為接收器集合分發(fā)相同的數(shù)據(jù)包。它利用網(wǎng)絡硬件并行處理的優(yōu)勢減少了內存的服務器上的負載。因為所有克隆具有類似的內存訪問模式，通過對所有克隆的第一個要求發(fā)送一個應答，每個克隆的要求被作為它的兄弟姐妹預處理。

不像其他的組播系統(tǒng)，mcdist并不一定是可靠的，沒有以一個有序的方式提供數(shù)據(jù)包，也沒有以原子方式提供所有擬接收的應答。組播是嚴格意義上的優(yōu)化，并確?？寺∶鞔_請求內存頁的需要。因此，該設計優(yōu)雅簡單：簡單的服務器多播的響應，而因為客戶端超時，當克隆沒有收到一個請求的答復時重新請求。

SnowFlock的三個優(yōu)化都體現(xiàn)在mcdist上：

? 一致性檢測：當時間局部性發(fā)生時，多個無差別請求都非常密切的繼承在同一頁。mcdist服務器忽略所有除第一個以外的請求。

? 流量控制：接收器的獲取率與請求相關。服務器的發(fā)送率取決于客戶端接受率的加權平均。否則，接收器將會淹沒在服務器發(fā)送過多的內存頁中。

? 游戲結束：當服務器已經(jīng)發(fā)送了大多數(shù)頁面時，將回到單播響應。在這一時間點上的大多數(shù)請求是重試，從而通過網(wǎng)絡的內存頁轟炸所有克隆是不必要的。

18.5.3虛擬磁盤

SnowFlock的克隆，由于其短壽命和命運決定，很少使用的磁盤。SnowFlock 虛擬機的虛擬磁盤包括了二進制文件，庫和配置文件的根分區(qū)。通過合適的文件系統(tǒng)如HDFS 或PVFS 是完成大量的數(shù)據(jù)處理。因此，當SnowFlock克隆決定從他們的根磁盤讀取數(shù)據(jù)時，它們通常由內核的文件系統(tǒng)頁面緩存來滿足這樣要求。 盡管如此，我們仍需提供克隆的虛擬磁盤訪問，在一些罕見的實例中這種訪問需求是需要的。我們在這里采用了最小阻力路徑，依據(jù)內存復制的設計來實現(xiàn)虛擬磁盤訪問。首先，在克隆的時間里磁盤的狀態(tài)被凍結。父虛擬機保持以CoW的方式使用其磁盤：對存儲備份的寫操作被發(fā)送到單獨的位置，在磁盤克隆時也是不可改變的。二，磁盤的狀態(tài)將使用 mcdist組播到所有克隆，且具有相同的4 KB頁的粒度，并根據(jù)時間局部性完成相同的期望。第三，嚴格復制克隆虛擬機的磁盤狀態(tài)是短暫的：它存儲在一個文件中，當克隆被摧毀后被刪除。

18.6克隆端組件

克隆在從架構描述器創(chuàng)建時是空心彈，和我們一樣，他們需要從父母那里獲得很大的幫助才能長大：子虛擬機們遷出時要立即給家里打電話，他們發(fā)現(xiàn)很多需要的東西缺失，要求他們的父母馬上發(fā)送。

18.6.1 memtap進程

memtap進程連接到每個創(chuàng)建后的克隆，是一個克隆的生命線。它映射到克隆的所有內存并按需加載。通過Xen的hypervisor，它登記了一些關鍵的數(shù)據(jù)位：訪問克隆內存的權限被關閉，由第一次訪問一個內存頁造成的硬件故障由hypervisor路由到memtap進程。

在其最簡單的化身中，memtap進程只需簡單地要求內存的服務器處理錯誤內存頁，但也有更復雜的情況。首先，memtap助手使用了mcdist。這意味著，在任何時間點，任何頁面可以憑借已被另一個克隆的異步預取請求到達克隆。第二，我們允許SnowFlock虛擬機是多處理器的虛擬機。這就不那么有趣了。這意味著，在并行處理時存在同一頁的多個故障需要。第三，在以后的版本中,memtap助手可以明確地預取批量的內存頁，在缺乏保證情況下,以任何次序從mcdist服務器到達克隆。這些因素可能導致并發(fā)噩夢，我們遇到了所有這些問題。

內存頁位圖是整個memtap的設計中心。當處理架構描述器創(chuàng)建克隆虛擬機時，創(chuàng)建和初始化該位圖。該位圖是一個比特數(shù)組,其大小由虛擬機內存可容納的內存頁數(shù)量決定。英特爾處理器有方便的原子位互斥指令：設置了一個比特，或做一個測試和設置，可以保證原子發(fā)生與其他處理器在同一個盒子里。這使得我們在大多數(shù)情況下，從而提供不同的實體，在不同的保護域的訪問位圖以避免鎖：Xen管理程序，memtap進程，以及guest內核本身的克隆。

當Xen的處理由第一次訪問頁面產(chǎn)生的硬件頁錯誤時，它使用內存頁位圖來決定是否需要提醒 memtap。它還使用該位圖依賴于不在同一頁的多個虛擬處理器來隊列化memtap緩沖頁。當其緩沖區(qū)是滿的，或到達一個明確請求的內存頁時暫停虛擬機，位圖被用來丟棄那些已經(jīng)到達的任何重復的已經(jīng)存在內存頁。所需的任何剩余內存頁被復制到虛擬機的內存，并設置適當?shù)奈粓D比特。

18.6.2 明智的克隆，避免不必要的提取

我們剛剛提到，運行于克隆內核的該內存頁位圖是可見的，并沒有鎖，需要修改。這給克隆提供了一個強大的“啟蒙”工具：它們可以防止通過修改位圖和假裝已經(jīng)存在的是當前內存頁的抓取。這是非常有用的性能，在內存頁沒有完全覆蓋之前，他們都可以被安全使用。

恰好是一個非常普遍的情況，當發(fā)生這種情況，并獲取可避免。在內核中的所有內存分配（虛擬機alloc的使用 ，kzalloc，get_free_page，用戶空間的BRK，等等）最終處理內核頁分配器。內存頁通常由中間開始分配，管理細粒度塊要求是：slab分配器，glibc在一個用戶空間進程的malloc分配，等等。然而，無論是顯式或隱式的分配，一個關鍵的語法含義始終正確：沒有人關注內存頁中包含的內容，因為它的內容將隨時被覆蓋。為什么取這樣一個內存頁呢？沒有任何理由這樣做，實際經(jīng)驗表明，避免這種獲取方式是極其有利的。

18.7虛擬機克隆的應用程序接口

到目前為止，我們都集中一個虛擬機有效克隆的內部機制。作為服務系統(tǒng)非常有趣，所以我們需要把注意力放在誰將使用這樣的系統(tǒng)：應用。

18.7.1。API實現(xiàn)

通過簡單的SnowFlock API（如圖18.1所示），應用程序可以利用虛擬機克隆。利用克隆的方式基本上是一個兩階段的過程。你第一次請求分配一個克隆實例，雖然依賴于系統(tǒng)策略的影響，分配的實例可能會小于所請求的內容。第二，你可以使用分配給你的虛擬機克隆。一個關鍵的假設是你的重點聚焦于虛擬機上一個操作。虛擬機克隆是適用于單一應用的虛擬機，如Web服務器或一個渲染工廠組件。如果你在一百多個桌面環(huán)境進程中的多個應用程序同時調用虛擬機克隆，你就頭大了。

sf_request_ticket（N） 請求分配n個克隆。返回一個分配M≤N 克隆的ticket。

sf_clone（ticket） 使用的ticket分配克隆。返回克隆ID，0≤ID

sf_checkpoint_parent（） 準備一個檢查點?不可改變的父虛擬機，可用于以后任意創(chuàng)建克隆。

sf_create_clones（C，門票） 與sf_clone相同，只是使用檢查點?。在哪個對應點開始執(zhí)行

sf_checkpoint_parent（）時調用克隆。

sf_exit（） 終止子克?。?≤ID

sf_join（ticket） 父節(jié)點使用（ID = 0），塊，直到所有使用ticket的子節(jié)點調用sf_exit前一直處于阻塞狀態(tài)。在這一時間點上，所有的子節(jié)點都被終止和ticket被棄用。

sf_kill（ticket） 家長棄用ticket票，并立即殺死所有相關的子節(jié)點進程。

表18.1：SnowFlock虛擬機克隆API

API簡化了編組消息，同時傳遞給XenStore，Xen通過共享內存的低吞吐量接口來控制平面交易。在hypervisor上運行的一個SnowFlock本地守護進程（SFLD）執(zhí)行監(jiān)聽這樣的請求，包括消息解組，執(zhí)行，并要求回調。

通過API，程序可以直接控制虛擬機的克隆。API編程語言包括C，C + +，Python和Java。我們既可以使用shell腳本執(zhí)行程序，也可以使用所提供的命令行腳本。并行框架（如MPI）可以嵌入到API中：MPI程序就可以使用SnowFlock了，且并不需要修改源代碼。置于Web服務器或應用服務器前的負載平衡器可以使用API克隆他們所管理的服務器。

SFLDs協(xié)調虛擬機克的隆執(zhí)行請求。他們創(chuàng)建和傳輸架構描述器，創(chuàng)建克隆的虛擬機，啟動磁盤和內存的服務器，并啟動memtap輔助進程。他們是分布在一個物理集群系統(tǒng)上負責管理虛擬機的一個微型發(fā)布系統(tǒng)。

SFLDs推遲分配的決策給一個集中SnowFlock的主守護進程（SFMD）。SFMD使用相應的集群管理軟件簡化了接口。我們沒有看到任何需求需要推倒重來，包括資源分配，配額，策略等，例如Sun的網(wǎng)格引擎或平臺的EGO等都是適合的。

18.7.2必要的突變

克隆后，大多數(shù)克隆的虛擬機進程不再是父節(jié)點，而且他們現(xiàn)在運行在一個副本上。在大多數(shù)情況下，這是正常的，沒有問題。畢竟，操作系統(tǒng)的主要任務是從低層次的細節(jié)（如網(wǎng)絡標識）隔離應用程序。然而，平穩(wěn)過渡需要一套有效的機制。如果管理在克隆的網(wǎng)絡身份以避免沖突和混亂，我們就必須引入在克隆過程中的輕微突變。此外，因為這些調整可能需要更高級別的權限，所以允許用戶配置一個鉤子程序來插入到任何必要的任務中，例如依靠克隆的身份安裝網(wǎng)絡文件系統(tǒng)。

克隆的產(chǎn)生有可能是不必要的。盡管父虛擬機可能是由DHCP服務器管理的網(wǎng)絡的一部分，或系統(tǒng)管理員通過其他各種途徑能夠做到克隆的IP地址分配。為了保持靈活的應用場景，我們將父節(jié)點和所有克隆置于虛擬的私有網(wǎng)絡中。從同一父節(jié)點的克隆都分配一個唯一的ID，他們的IP地址在這個私有網(wǎng)絡中被自動設置后，克隆的ID生效。這保證了不需要系統(tǒng)管理員的干預參與，而且沒有IP地址沖突。

我們通過一個鉤子程序在虛擬的網(wǎng)絡驅動程序直接對IP進行重新配置。然而，我們也催動驅動程序自動生成合成的DHCP響應。因此，無論你如何分發(fā)，虛擬的網(wǎng)絡接口將確保正確的IP地址傳播到客戶機操作系統(tǒng)，甚至當你重新啟動主機是都可以。

為了防止來自不同父母的克隆碰撞以及隔離彼此的虛擬專用網(wǎng)絡，可以防止相互DDoS攻擊克隆虛擬網(wǎng)絡的以太網(wǎng)（或第二層交換）。我們劫持了以太網(wǎng)MAC OUIs范圍3，奉獻他們的克隆。OUI將是一個父虛擬機的功能。像通過一個虛擬機的ID確定其IP地址一樣，這同樣決定了其非OUI的以太網(wǎng)MAC地址。虛擬的網(wǎng)絡驅動器具有將虛擬機的MAC地址轉換成它所分配虛擬機ID的功能，過濾出所有虛擬專用網(wǎng)絡與不同OUI們的流量。這種隔離是通過 ebtables簡單實現(xiàn)的。

讓彼此克隆間通信可能是有趣的，但不是情趣盎然。有時我們會想讓克隆響應來自互聯(lián)網(wǎng)的HTTP請求，或連接公共數(shù)據(jù)倉庫。我們?yōu)樘摂M機的任何一套父節(jié)點和克隆配備一個專用的路由器。這個路由器的小虛擬機執(zhí)行從克隆到互聯(lián)網(wǎng)的防火墻，節(jié)流和NAT的功能。這也限制了父虛擬機的接入連接和眾所周知的端口。路由器的虛擬機是輕量級的，但代表了網(wǎng)絡流量的集中化，從而嚴重限制了可伸縮性的單點。相同的網(wǎng)絡規(guī)則，可用于每個克隆虛擬機運行主機的一個分布式環(huán)境。我們還沒有發(fā)布這個實驗室補丁。

SFLDs分配了虛擬機ID，并指導虛擬網(wǎng)絡驅動程序應該如何配置自己內部的MAC和IP地址，DHCP指令，路由器虛擬機的坐標，過濾規(guī)則，等等。

18.8結論

通過調整Xen hypervisor和延遲轉移虛擬機的狀態(tài)，SnowFlock可以在幾秒鐘內產(chǎn)生幾十個運行中的虛擬機克隆。SnowFlock克隆虛擬機的瞬時性和熱加載極大地改善了自動化集群管理的可用性和為應用提供云資源的更大可編程性。SnowFlock也提高了云的靈活性，虛擬機實例加快了20倍，并通過利用他們的父節(jié)點內存中的操作系統(tǒng)和應用程序緩存提高了最新創(chuàng)建的虛擬機的性能。SnowFlock高效性能的關鍵是啟發(fā)式，避免了不必要的頁面抓取，組播系統(tǒng)，讓克隆們合作預取它們的狀態(tài)。它是巧妙應用了一些嘗試和真正的技術，一些技巧，以及一些工業(yè)界調試的慷慨幫助。

我們認識到整個SnowFlock經(jīng)歷了兩個重要的教訓。首先是經(jīng)常被低估的價值KISS定理。我們期待實現(xiàn)復雜的預取技術，以減輕一連串的內存頁在克隆啟動時會發(fā)出的請求。令人驚訝的是這也許沒有必要。該系統(tǒng)作為以一個單一原則為基礎的許多工作有很好的表現(xiàn)：只是帶來了超出需要的內存。簡單化的另一個例子是內存頁位圖。通過一個簡單的數(shù)據(jù)結構和清晰的原子訪問語義，這大大簡化了由于多個虛擬CPU，頁面更新的競爭，通過多播的異步頁到達等可能產(chǎn)生的并發(fā)性問題。

第二個教訓是規(guī)模不再是謊言。換句話說，你發(fā)現(xiàn)每次你都會碰到準備切換系統(tǒng)和新出現(xiàn)瓶頸的規(guī)模性問題。這是緊密聯(lián)系在一起的教訓：隨著負載的增加，簡單而優(yōu)雅的解決方案使規(guī)模化隱藏了起來。這個原則的一個最好的例子是mcdist系統(tǒng)。在大規(guī)模的測試表明，一個以TCP / IP為基礎的頁面分配機制進行數(shù)百克隆時經(jīng)常慘遭失敗。mcdist憑借其極端的分發(fā)機制和角色良好定義的獲得了成功：客戶只關心自己的內存頁，服務器只關心維持一個全局的流量控制。保持mcdist優(yōu)雅簡單，使SnowFlock能夠擴展得非常好。

如果你有興趣了解更多，您可以訪問網(wǎng)站多倫多大學的網(wǎng)站1獲得在GPLv2授權許可下的學術論文和開放源碼，GridCentric 4為一個工業(yè)化的實現(xiàn)。

注：

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/