引言
虛擬機(Viaual Machine。VM)技術常常應用于數據中心、集群計算等場合。該技術讓多個操作系統(tǒng)可以運行在同一個物理機器上，并提供了可靠的隔離，大大提高了物理資源的復用性。
隨著虛擬機技術的盛行，VMM(Virtual MachineMonitor)的概念也隨之推廣，VMM是建它在虛擬機和硬件中間的隔離層，它可以有效地協(xié)調，分配和管理在虛擬機中運行的客戶操作系統(tǒng)。XEN是一種混合模式的VMM，它是準虛擬化技術的代表，這表示，為了調用系統(tǒng)管理程序，要有選擇地修改操作系統(tǒng)，而不需要修改操作系統(tǒng)上運行的應用程序。XEN占用資源少，其虛擬機性能與真實機器性能相差3％左右。
虛擬機遷移對于分布式數據中心和集群的負載均衡和災難恢復有非常重大的意義，Vmware、Intel和微軟目前都在進行虛擬機遷移相關的研究。虛擬機動態(tài)遷移停機時間很短，可使服務中斷最小，從而實現動態(tài)負載均衡和服務器在線維護，將成為新的發(fā)展趨勢。
1 相關工作
Collective項目把VM的遷移當作一種方法，該方法使得在不同時間使用不同位置物理主機的用戶得到便利，比如用戶在從家里到公司的途中，OS的實例從家里的計算機遷移到公司的計算機上。這個項目是在ADSL慢速連接上進行的，在遷移時停止了OS的執(zhí)行，并減小映像文件的大小，使得網絡帶寬占用小、總遷移時間比較快。相對的，本文是在比較快的網絡鏈接環(huán)境下，實現了更小的downtime。
Zap是基于修改后的Linux內核的項目，采用了部分的US虛擬化，支持名為pods的進程級虛擬機的遷移，這種進程虛擬機實際上是一組進程的集合。Zap的方法是把進程對內核的接口，如文件句柄、socket，都獨立出來并放到一個可遷移的容器中。這種方法比Collective項目的速度快，主要是因為遷移的單位更小，而且Zap的遷移也不支持動態(tài)遷移。
NomadBIOS}0是一個基于L4microkernel的虛擬化的遷移系統(tǒng)。NomadBIOS采用了pre-copy遷移來實現盡可能小的downtime。但它沒有涉及到工作集的概念。
本文小結了相關工作，采用了預拷貝技術，基于XEN的開源環(huán)境，進行了同一個局域網內不同物理機器之間的虛擬機動態(tài)遷移的研究。
2 虛擬機動態(tài)遷移模型
要實現動態(tài)遷移，必須達到以下幾點要求。
1）最小中斷:遷移時盡量使停機時間最小，因為在停機時間內任何服務都無法執(zhí)行。
2)一致性:總遷移時間不要太長，因為這段時間內2臺機器狀態(tài)必須同步，可能會影響穩(wěn)定性。
3)最小干擾:保證遷移不會通過資源爭奪來干擾正在活動的服務，如CPU、網絡帶寬。
4)透明性:遷移過程對用戶應該是透明的，在遷移期間，要維持所有的網絡連接、應用程序狀態(tài)。本文將通過預拷貝(pre-copy)方法來實現這個要求。
虛擬機的遷移包括文件系統(tǒng)、內存、網絡連接等完整的狀態(tài)和資源的遷移，這樣才能保證遷移后的虛擬機能在新的計算機上恢復且繼續(xù)運行。其中，文件系統(tǒng)的遷移可以通過網絡文件系統(tǒng)NFS的方式解決。XEN已經實現了局域網內的網絡連接重定向，通過發(fā)送ARP重定向包，將虛擬機的IP地址與目的機器的MAC地址相綁定，之后的所有包就可以發(fā)送到目的機器上。內存中數據量大，且內容是動態(tài)變化的，因此內存的遷移難度最大，本文將重點介紹內存遷移的部分。
2. 1內存遷移的階段
一般說來，內存遷移有三個階段。
1)push階段。一些頁面從源VM通過網絡被push到目的機器，而源VM運行不間斷，為了保證數據一致性，被修改了的頁面需要重傳。
2)stop-and-copy階段。源VM停止，頁面被傳送到目的VM，然后啟動新的VM。
3)pull階段。新的VM執(zhí)行，如果訪問到沒有被拷貝的頁面，出現頁錯誤并且從源VM處執(zhí)行pull得到該頁面。
實際的做法是選取三個階段中的1或2個。純粹的stopand-copy階段，雖然實現簡單，但是停頓時間、總遷移時間與VM分得的物理內存成正比，性能低下。本文采用了預拷貝遷移方法，由有限次push階段和stop-and-copy階段組成。pre-copy的push階段是分為多次迭代執(zhí)行的，在第一次傳送全部頁面，第n次傳送的頁面是第n一1次中被修改了的頁面。每個VM都有一定的頁面集合會經常被修改，這些頁面不利于pre-copy方法，被稱為可寫工作集。我們通過分析可寫工作集來限制pre-copy的迭代次數。
2.2遷移的步驟
我們把遷移過程視作兩個主機之間的事務交互，具體的步驟如下。
1)預遷移。在物理主機A上啟動一個VM。預先選好接受遷移VM的目的主機B。
2)預定。從主機A向主機B發(fā)起一個遷移請求。我們先確認B上有遷移所必須的資源，并且預定一個適當大小的VM容器。如果B上資源不夠，VM繼續(xù)在A執(zhí)行。
3)迭代的pre-copy。在第一次迭代中，所有的頁面被A傳送到B，后來的迭代過程只拷貝前一次傳送頁面中被修改的頁面。我們限制r最大迭代次數，并且對遷移造成的網絡負擔進行了限制，一旦達到最高限度將停止迭代。
4)stop-and-copy階段。掛起主機A上運行中的US實例，CPU狀態(tài)和任何其他的不一致的內存頁面被傳送。在這階段，A和B都有VM的掛起的拷貝。A上的拷貝為主，萬一失敗，將在A上繼續(xù)執(zhí)行。
5)提交。主機B通知A，它已經成功收到了一致的US映象，主機A收到這個消息后可以拋棄原來的VM，此時以主機B上的映像為主。
6)激活。已遷移的VM在B上被激活并正常運行。
假定源主機在遷移事務提交前一直穩(wěn)定，VM在源主機上可以安全的掛起、重啟動，這個方法可以保證在遷移過程中任何時候至少一個主機有此VM的映象。這樣不管遇到什么錯誤，都可以在本地恢復。
2.3模型的優(yōu)化
XEN是準虛擬化的VMM，可以讓US感知到真實的和虛擬的環(huán)境的區(qū)別，這種優(yōu)點使得遷移時的優(yōu)化成為可能。我們在遷移前先通知US，并且在以下幾個方面改進性能。
1)寫錯誤的限制。pre-copy遷移時最好的情況是，內存頁面被復制到目的主機的速度比變臟的速度快。但是實際情況通常相反。在遷移開始時在OS內核中fork一個監(jiān)控線程，這個監(jiān)管線程可以監(jiān)視每個進程的工作集。在每個進程進人等待隊列前，給它們加上不得超過40個寫錯誤的限制，這樣就可以轄制妨礙到遷移的進程，但是必須保證不會打擊到一些重要的交互式服務。
2)釋放page cache的頁面。在OS中，總會有一些空閑頁面，可能是完全空閑的或者在冷卻的buffer cache中，遷移開始前，US可以把這些頁面中的一些或者全部都交給XEN，這樣第一次復制的時間就被減少很多。不過再次需要這些頁面的內容時候，就要從磁盤中讀了，這樣引起更大的開銷，需要權衡二者利弊。
3 動態(tài)遷移模型的評測
3. 1評測環(huán)境
1)硬件環(huán)境:實驗在兩臺支持Intel VT-x技術的計算機上進行，這兩臺機器配置如下:
CPU：Intel Core 2 6320 1 .86 CHZ
內存:1024 MB
磁盤:60 GB
網絡連接:100 Mbps以太網
2)軟件環(huán)境:實驗在安裝了XEN 3. 1. 0的Fedora7(2. 6. 18)系統(tǒng)上進行。在下面的實驗中，若無特殊說明，所有的虛擬機都是分配了6GB的磁盤空間，2個VCPU，通過XEN模擬的RTL8139虛擬網卡借由Domain0連到網絡。另外根據不同實驗口的，在虛擬機上安裝了相應的軟件。
3.2評測方案設計
本文把遷移過程中因虛擬機停止運行而造成的服務中斷時間稱為停機時間，而將虛擬機開始遷移到整個遷移結束的時間稱為總遷移時間。實驗主要分為動態(tài)遷移(live)和靜態(tài)遷移(non_live)兩種遷移方式，live方式采用了pre-copy方法，non_live方式是純粹的stop-and-copy，故其總遷移時間就是停機時間。
為了測量不同大小內存對虛擬機遷移的影響，分別測試了128MB，256MB，512MB內存下不同虛擬機的遷移情況。另外不同的負載情況一也會影響虛擬機遷移過程，本文設計了CPU密集型、內存密集型、I/0密集型的遷移實驗，另外做了一組無負載的遷移實驗作為對比。以卜是兒種實驗方案的具體設置和實驗數據。
1)無負載型。這組實驗遷移的是基礎系統(tǒng)，在虛擬機中沒有安裝任何軟件。由于是在無負載的情況下進行實驗，臟頁率比較低，所以迭代次數很少。
表1無負載虛擬化系統(tǒng)的遷移
2)CPU密集型。通過這組實驗測量CPU密集的情況對虛擬機遷移的影響。采用的方法是在遷移的同時，編譯虛擬機的內核。
在這組實驗中，停機時間是無負載情況下的7倍左右，128MB，256MB，512MB情況下分別是靜態(tài)遷移的停機時間的34.9%，15.9%，8.70%，停機時間隨內存的增加有所縮短。由于在編譯內核時進行遷移，臟頁率較無負載時高，但臟頁速度沒有超過遷移速度，沒有達到迭代終止條件，當達到預設的最大迭代次數(30)時，才進行停機拷貝。
表2 CPU密集型虛擬化系統(tǒng)的遷移
3)I/O密集型。通過這組實驗測量I/O密集的情況對虛擬機遷移的影響。使用netperf工具，讓控制域Domain0成為server端，虛擬機作為client端，在遷移的同時，虛擬機不斷向Domain0發(fā)包，從而形成I/O密集型的遷移。
表3 網絡I/O密集型虛擬化系統(tǒng)的遷移
在這組實驗中，停機時間是無負載情況下的2到3倍左右，128MB，256MB，512MB情況下分別是靜態(tài)遷移的停機時間的8.88%，3.61%，3.00%，停機時間與內存大小沒有明顯的關系。由于頁速度快，大于遷移速度，因此遷移開始后不久即達到迭代終止條件，迭代次數較少，但略多于內存密集型。
4)內存密集型。通過這組實驗測量內存密集的情況對虛擬機遷移的影響。用C語言編寫了一個寫內存的小程序，在遷移的同時，運行這個程序則自動向虛擬機內存執(zhí)行寫操作，每次寫人數據量為虛擬機內存大小的一半，形成內存密集型的遷移。
表4 內存密集型負載虛擬化系統(tǒng)的遷移
表5 不同負載情況的比較
在這組實驗中，停機時間是無負載情況下的2倍左右，128MB，256MB，512MB情況下分別是靜態(tài)遷移的停機時間的7.53%，4.39%，1.96%，停機時間與內存大小沒有明顯的關系。這種情況臟頁率最高，臟頁速度遠遠大于遷移速度，因此遷移開始后不久即達到迭代終止條件，迭代次數非常少，僅比無負載情況略有增加。
3.3評測結果分析
1)不同內存大小。由圖1-3可知，內存大小對于遷移時間有明顯影響。live方式的遷移，總遷移時間與內存大小基本成正比，然而停機時間與內存大小無關;non_live方式的遷移，停機時間與內存基本成正比。
2)動態(tài)和靜態(tài)遷移。從圖1-圖3來看，live方式的總遷移時間總是比non_ive方式要長。由表1一表4可知在CPU密集型實驗中，live方式總遷移時間是non_live方式的2到3倍，其他幾種負載live方式是non_live方式的1.2倍左右。
圖1 128MB內存在四種負載情況下的遷移時間
圖2 256MB內存在四種負載情況下的遷移時間
圖3 512MB內存在四種負載情況下的遷移時間
但live方式的停機時間總是遠遠小于non_live方式的停機時間，128MB，256MB，512MB的停機時間分別是non_live方式的4.8%，2.1%，1%。
說明live方式比non_live方式總遷移時間稍長但可以忍受，而且被遷移虛擬機的服務中斷時間要少很多，可以提高虛擬機在遷移時的可用性。
3)不同負載對遷移時間的影響。從圖1一圖3可以看出，在內存大小相同的情況下，負載的不同導致總遷移時間和停機時間也不相同。由表1一表4可知，I/O密集和內存密集型的總遷移時間分別為無負載時的1.07倍、1.2倍，而CPU密集型負載是無負載時的2.2倍;I/O密集和內存密集型的停機時間分別為無負載時的2.15倍、1.84倍，而CPU密集型負載是無負載時的7.75倍。說明CPU密集型負載對XEN的動態(tài)遷移影響比較大。
4 結語
本文在總結相關工作的基礎上，研究了虛擬機動態(tài)遷移方法，并設計了4種不同負載下的遷移實驗。實驗數據表明CPU密集型負載對遷移的影響最大，I/O和內存密集型影響較小。動態(tài)遷移方式的停機時間總是遠遠小于傳統(tǒng)靜態(tài)遷移方式的停機時間，內存越大，靜態(tài)遷移停機時間越長，但動態(tài)遷移停機時間變化不大，說明動態(tài)遷移可以顯著改善服務性能。本文主要在局域網進行遷移，今后會向廣域網遷移發(fā)展，為了保持虛擬機的網絡連接，需要采用移動IP或者動態(tài)DNS等網絡重定向技術}SJ;如果在集群中要遷移整個磁盤內容，可以在目的主機上建立一個cow的磁盤鏡像，支持塊設備遷移。
核心關注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理，全面涵蓋了企業(yè)關注ERP管理系統(tǒng)的核心領域，是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.oesoe.com/
本文標題：虛擬機動態(tài)遷移的研究
相關文章
