一、前言

上篇我們分析了基于KVM的虛擬化遷移技術(shù)原理，通過這種虛擬化遷移技術(shù)能夠提供很好的在線遷移解決方案。

但是考慮到云平臺環(huán)境的復(fù)雜性，以及用戶需求的多樣性，在遷移過程中我們需要解決以下幾個問題：

• 宿主機的選擇;
• 磁盤鏡像處理;
• 網(wǎng)絡(luò)切換設(shè)置;
• 內(nèi)存磁盤壓力的處理等。

因此，UCloud云平臺需要對在線遷移過程進行多方面的優(yōu)化，本篇文章將具體分析UCloud在不同應(yīng)用場景下對KVM虛擬化遷移技術(shù)各個階段所做的優(yōu)化。

二、普通遷移優(yōu)化

1. 準備階段

在遷移準備階段，需要選擇相同業(yè)務(wù)類型的宿主機，以便方便創(chuàng)建相同配置的虛擬機。該機型除了具有足夠空閑內(nèi)存和磁盤的物理機外，還需要考慮目標物理機的配置是否合適。特別是需要考慮CPU的型號和內(nèi)核的版本號。

另外，考慮到遷移過程網(wǎng)絡(luò)帶寬有限，如果帶寬被其他任務(wù)占用，就會使得遷移速度下降，甚至影響最終遷移的成功率。為此，除非物理機之間的網(wǎng)絡(luò)帶寬足夠大，在UCloud平臺上原則上并不允許在相同兩臺物理機之間進行多個并行的遷移任務(wù)，以便盡量確保在線遷移的成功率。

2. 遷移階段

在線遷移過程中需要遷移虛擬機的所有磁盤和內(nèi)存數(shù)據(jù)，而且虛擬機在遷移過程中并不停機，這使得需要遷移更多的增量數(shù)據(jù)。如果能夠減少數(shù)據(jù)的遷移量，就能夠減少遷移時間，從而更快的實現(xiàn)云平臺的資源動態(tài)調(diào)整和故障處理。

(1) 零數(shù)據(jù)優(yōu)化：

UCloud的虛擬機使用的是本地存儲(UDisk除外)，磁盤在物理機上是以文件方式存在的，這個文件是sparse文件，假設(shè)虛擬機的磁盤是100G，但實際使用了10G，那么這個磁盤文件在物理機上只占用了10G空間。如圖 2‑1所示，但是原生的Qemu在遷移磁盤時并沒有保持sparse特性，所以這個100G的磁盤遷移到目標物理機上后就實際占用了100G空間。這個對物理機的磁盤空間來說是非常浪費的，而且還嚴重影響遷移的完成時間。

圖 2‑1磁盤文件零塊數(shù)據(jù)遷移前后示意圖

圖 2‑2 磁盤文件零塊數(shù)據(jù)遷移優(yōu)化示意圖

如圖 2‑2 所示，我們的優(yōu)化方案就是在源端讀到全0的塊，就不發(fā)送到目標端，這樣目標端就是跳著塊來寫一個文件，這樣就保持了磁盤文件的sparse特性。同時，考慮到線上往往存在多種Qemu版本，還要考慮到原生的Qemu和打了這個patch的Qemu之間遷移機器如何保持sparse。為此，可以通過在Qemu中接收磁盤數(shù)據(jù)過程判斷一個塊是否全部為0，如果是就不實際寫磁盤，即可解決。所有的零塊數(shù)據(jù)都被跳過，不進行傳輸。

通過上述方法就可以忽略磁盤遷移過程中的零數(shù)據(jù)，大大減少傳輸?shù)臄?shù)據(jù)量。最終，通過Qemu的這些patch，還可以明顯減少在線遷移的數(shù)據(jù)傳輸量和鏡像文件的空間占用量。

(2) UDisk網(wǎng)絡(luò)盤優(yōu)化

由于UDisk是網(wǎng)絡(luò)塊存儲，在遷移一臺帶有UDisk機器時， 遷移UDisk盤是沒有必要的，因為這個盤可以通過網(wǎng)絡(luò)掛到目標。為此，我們在遷移時過濾掉虛擬機的UDisk盤，同時對UDisk產(chǎn)品做了改造，支持多點掛載，這樣就解決了這個問題，提高了遷移的效率。

在遷移前目標端DestHost會將UDisk進行掛載操作，同時遷移過程中會跳過UDisk的傳輸，當遷移結(jié)束時源端SourceHost會將UDisk進行卸載，這樣既避免對UDisk數(shù)據(jù)進行遷移，同時避免虛擬機在遷移過程中，對UDisk數(shù)據(jù)的訪問，實現(xiàn)遷移過程對用戶完全透明。

(3) 遷移結(jié)束優(yōu)化

目前，在線遷移默認情況下它不能很好地處理內(nèi)存寫密集型的虛擬機。由于在線遷移過程中，用戶虛擬機并不關(guān)機，這就使得遷移過程中用戶會不停產(chǎn)生新的內(nèi)存臟數(shù)據(jù)。這些新增臟數(shù)據(jù)需要通過多次迭代的增量數(shù)據(jù)遷移來傳遞到目標端DestHost上，并在預(yù)期新增臟數(shù)據(jù)傳輸時間少于最大停機時間時，進行最后一次停機增量數(shù)據(jù)傳輸，然后將虛擬機切換到目標端DestHost。

如果用戶產(chǎn)生的臟內(nèi)存數(shù)據(jù)過多，就會使得遷移的增量數(shù)據(jù)傳輸時間一直大于最大停機時間，使得增量傳輸階段不斷進行循環(huán)迭代，導(dǎo)致整個遷移過程無法完成。

圖 2‑3 內(nèi)存遷移的auto-coverge優(yōu)化

由于用戶產(chǎn)生臟內(nèi)存數(shù)據(jù)的速度與虛擬機的vCPU被提交運行的時間有關(guān)，因此能夠減少用戶虛擬機vCPU執(zhí)行時間可以阻止用戶產(chǎn)生過多的內(nèi)存臟數(shù)據(jù)，從而讓遷移數(shù)據(jù)傳輸?shù)靡栽趦?nèi)存臟數(shù)據(jù)產(chǎn)生之前的完成。

為此，我們對Qemu的auto-converge功能進行了優(yōu)化，首先，我們提高了Qemu的throttling遷移速度，避免遷移速度限制遷移的完成時間。其次，我們修改了auto-converge的觸發(fā)條件。在增量遷移數(shù)據(jù)時，如果產(chǎn)生臟數(shù)據(jù)的量大于上次產(chǎn)生傳輸數(shù)據(jù)量的50%，并重復(fù)發(fā)生多次，則自動觸發(fā)自動auto-converge功能。該功能默認情況下，將削減20%的虛擬機vCPU執(zhí)行時間，也就減低用戶虛機vCPU的執(zhí)行速度，并減少新增的臟數(shù)據(jù)。

在每次內(nèi)存迭代開始時，它會根據(jù)之前的削減情況，決定后續(xù)削減粒度。如果新增臟數(shù)據(jù)仍然過多，它將重復(fù)削減10%的許可vCPU的運行時間，直至削減CPU直至99%，從而觸發(fā)最后階段的停機遷移，以完成遷移過程。

雖然這種優(yōu)化會使得虛擬機的停機時間稍長，但是根據(jù)長期實踐結(jié)果，整個遷移的停機時間仍然非常小(小于100ms)，因此這項優(yōu)化對提高遷移的成功率有重要意義。

(4) 壓縮遷移優(yōu)化

雖然Qemu的auto-converge功能可以在一定程度上解決用戶內(nèi)存負載對遷移的影響，提高遷移成功率，但如果用戶產(chǎn)生的臟數(shù)據(jù)對vCPU的執(zhí)行速度依賴不大，則會使遷移的增量數(shù)據(jù)傳輸時間一直大于最大停機時間，使整個遷移過程無法完成。考慮到內(nèi)存負載高的用戶，往往會反復(fù)修改某一內(nèi)存頁，這些內(nèi)存頁面很容易被壓縮。為此，可以考慮在遷移內(nèi)存數(shù)據(jù)前進行壓縮。

如圖 2‑6所示，當前Qemu支持的XBZRLE壓縮算法會將之前發(fā)送的內(nèi)存頁面維護在其內(nèi)存緩存區(qū)內(nèi)。在遷移內(nèi)存頁面時，會先查找該頁面是否在其XBZRLE緩存內(nèi)，如果在緩存內(nèi)，則進行異或編碼，只傳輸被壓縮后的增量數(shù)據(jù);如果沒有，則直接傳輸內(nèi)存頁面。通過這個過程可以大大減少發(fā)送內(nèi)存頁面數(shù)據(jù)量，并提高內(nèi)存遷移速度。

圖 2‑4內(nèi)存遷移的xbzrle壓縮遷移優(yōu)化

目前，UCloud的在線遷移已經(jīng)使用XBZRLE進行高內(nèi)存負載的遷移優(yōu)化。實際使用表明通過這種壓縮方法可以提高高內(nèi)存負載虛擬機的遷移成功率、并縮短遷移時間，同時CPU使用率提高也在合理范圍內(nèi);對于普通內(nèi)存負載虛擬機的遷移，幾乎沒有額外的CPU使用率消耗。后續(xù)還會結(jié)合底層硬件加速卡，并適時的開啟多線程內(nèi)存壓縮遷移優(yōu)化。

三、切換階段

1. 源端paused優(yōu)化

遷移的過程是由Qemu來具體執(zhí)行，但是對于整個遷移過程的控制則是來自更上層的Libvirt。當Qemu在執(zhí)行最后一步機器數(shù)據(jù)遷移切換時，兩邊的虛擬機都是處于paused狀態(tài)。后續(xù)Libvirt將關(guān)閉源端SourceHost上的被遷移虛擬機，并拉起目標端DestHost上的對應(yīng)虛擬機。

在線遷移的最大優(yōu)點在于不能因為遷移失敗而導(dǎo)致虛擬機關(guān)機，不管成功或者失敗，都要保障虛擬機實例的存活(源端或目標端)。為了加強遷移過程的保障，避免源端和目標端關(guān)機的情況出現(xiàn)，我們將Libvirt中遷移過程源端開關(guān)機的控制邏輯移到UCloud自身的運維管理平臺中，以便在出現(xiàn)遷移異常時，及時恢復(fù)源端SourceHost上的虛擬機。這個改造上線以來，多年未出現(xiàn)過由于遷移導(dǎo)致虛擬機宕機的情況。

2. OVS切換優(yōu)化

此外，我們在遷移過程中觀察到，在遷移即將完成時存在數(shù)秒網(wǎng)絡(luò)中斷的情況，這會導(dǎo)致用戶業(yè)務(wù)出現(xiàn)短暫中斷，使得后臺的遷移過程對用戶不透明。而且為減少對用戶業(yè)務(wù)造成不利影響，往往需要事先和用戶協(xié)調(diào)溝通遷移事項，限制了在線遷移的應(yīng)用。

為此，我們通過大量的測試遷移實驗發(fā)現(xiàn)最后一輪的虛擬機的遷移關(guān)機時間downtime基本在70ms左右，并不是長時間網(wǎng)絡(luò)中斷的主要原因，而且虛擬機內(nèi)部壓力和遷移速度的變化對遷移downtime并無明顯影響。考慮到UCloud的虛擬機網(wǎng)絡(luò)是采用openswitch來定義組建的，經(jīng)過大量實驗確認遷移過程中的網(wǎng)絡(luò)中斷時間和openswtich設(shè)置目標端虛擬機新flow規(guī)則的延時時間存在正相關(guān)關(guān)系。

因此，UCloud專門為在線遷移開發(fā)了網(wǎng)絡(luò)下發(fā)虛擬機新flow的接口。在虛擬機遷移后到目標端DestHost后，及時為虛擬機下發(fā)的新flow規(guī)則。通過優(yōu)化openswtich的網(wǎng)絡(luò)配置機制，目前已經(jīng)將遷移過程中的網(wǎng)絡(luò)中斷時間控制在幾百毫秒左右，基本做到用戶無感知，不會因為在線遷移造成用戶業(yè)務(wù)的中斷。

四、典型應(yīng)用場景優(yōu)化

1. 快速遷移場景

在通過上述在線遷移優(yōu)化之后，UCloud平臺上的在線遷移方案已經(jīng)可以達到很好遷移成功率，為保證用戶虛擬機的性能和可靠性提供了重要保障。但是，考慮到部分用戶存在大容量的數(shù)據(jù)盤，如果進行正常在線遷移，整個遷移時間非常長，無法快速降低源物理機的負載，不利于資源動態(tài)調(diào)整和故障處理。特別是如果用戶虛擬機正在運行高IO負載業(yè)務(wù)，會導(dǎo)致磁盤遷移過程遲遲無法結(jié)束，最終導(dǎo)致遷移失敗。為此，UCloud平臺針對這種場景專門進行了磁盤高負載虛擬機的快速遷移優(yōu)化。

考慮到正常在線遷移在目標端DestHost上拉起虛擬機之后，需要先通過磁盤遷移來確保目標端DestHost上虛擬機訪問的磁盤數(shù)據(jù)和源端SourceHost相同。為此需要跳過磁盤遷移進行快速的遷移方案。

如圖 3‑1所示，首先就需要打通目標端DestHost和源端SourceHost之間的存儲系統(tǒng)，即共享兩個Host上虛擬機鏡像的磁盤數(shù)據(jù);同時，在此基礎(chǔ)上進行共享存儲的跨機遷移，從而實現(xiàn)先進行虛擬機內(nèi)存和CPU等數(shù)據(jù)的遷移，以便在目標端DestHost快速拉起虛擬機，緩解源端SourceHost的內(nèi)存和CPU壓力。之后，再將虛擬機的大磁盤數(shù)據(jù)從源端SourceHost拉取到目標端DestHost。最后，刪除源DestHost和目標SourceHost直接的共享存儲。

具體快速在線遷移的具體實現(xiàn)步驟如下：

圖 3‑1遠程拉取磁盤數(shù)據(jù)示意圖

通過快速遷移優(yōu)化，整個完整的遷移過程所需的時間，和傳統(tǒng)的遷移方法所需的時間相當。但是遷移過程中，共享存儲遷移的過程非常短暫，可以快速的在目標端DestHost上拉起虛擬機VM，迅速降低源端SourceHost的負載，改善用戶VM之間的資源競爭，改善用戶VM的性能，特別對于具有大數(shù)據(jù)盤的VM用戶具有重要意義。

目前，UCloud平臺的快速遷移方法已經(jīng)全面上線，已經(jīng)成功為眾多用戶完成快速跨機遷移，幫助用戶解決VM的性能和可靠性問題。

2. 跨機型場景

前述各種遷移方法，通常用于相同類型的云主機之間進行遷移，特別是目標端云主機和源云主機上的虛擬機配置需要完全一致。在UCloud云平臺，除了存在普通云主機機型外，還存在類似方舟機型、SSD機型等許多不同存儲類型的虛擬機，這些不同類型的云主機上所使用的虛擬機的磁盤配置并不完全相同。

當用戶存在這種機型切換要求時，以往的做法往往需要對用戶虛擬機停機進行機型類型轉(zhuǎn)換遷移，造成用戶業(yè)務(wù)中斷，不利于用戶根據(jù)不同業(yè)務(wù)需要進行不同機型切換。但是當用戶提出這種跨機型遷移需求時，往往伴隨著其關(guān)鍵業(yè)務(wù)負載無法滿足要求，或者關(guān)鍵業(yè)務(wù)需要在更加安全可靠的環(huán)境下運行，如果對關(guān)鍵業(yè)務(wù)進行停機切換往往是無法接受的，也極大的限制了云平臺的彈性擴展特性。

為了滿足用戶的業(yè)務(wù)需求進行機型升級切換，同時不停止虛擬機保證用戶業(yè)務(wù)在升級過程中繼續(xù)運行，為此UCloud專門開發(fā)了跨機型的特殊在線遷移方案。針對這種跨機型的特殊遷移，其關(guān)鍵點在于解決磁盤設(shè)備的類型轉(zhuǎn)換問題。在UCloud云平臺上，用戶虛擬機作為一個Qemu進程運行，該進程需要根據(jù)底層的磁盤鏡像類型，選用不同底層塊設(shè)備驅(qū)動進行數(shù)據(jù)讀寫。

為此，在進行這種特殊跨存儲遷移時，需要通過Libvirt的特殊配置，先在目標端建立一個不同存儲類型的虛擬機(其他配置完全一樣)，然后再進行后續(xù)數(shù)據(jù)遷移。

如下圖 3‑2所示，通過這種特殊配置之后，源端Qemu將通過qcow2驅(qū)動從qcow2磁盤文件中讀取客戶磁盤數(shù)據(jù)，再通過網(wǎng)絡(luò)發(fā)送到目標端，目標端Qemu在接收到數(shù)據(jù)之后，通過raw驅(qū)動將數(shù)據(jù)寫入到lvm塊設(shè)備中。

通過多次的反復(fù)迭代最終完成整個磁盤的遷移，并最終將源端普通云主機上的用戶虛擬機遷移切換到目標端SSD機型的云主機上。整個遷移過程對用戶是透明的，不會對用戶業(yè)務(wù)造成不利影響，即便目標端虛擬機遷移失敗也不會影響源端用戶虛擬機的正常運行。

圖 3‑2跨機型遷移的存儲格式變換示意圖

通過這種特殊的跨機型在線遷移，目前UCloud平臺可以實現(xiàn)普通云主機到SSD云主機的相互遷移，也可以實現(xiàn)普通云主機到方舟高可靠機型的相互遷移，甚至通過這種遷移實現(xiàn)底層磁盤類型的轉(zhuǎn)換，從而方便用戶根據(jù)業(yè)務(wù)需要切換不同的云主機類型，而且不需要中斷線上業(yè)務(wù)，實現(xiàn)云平臺的彈性和擴展性的提高。

目前，這種跨機型的遷移技術(shù)在國內(nèi)云服務(wù)提供商中算是首創(chuàng)，大大提高用戶選擇的彈性度，有利于用戶按需根據(jù)業(yè)務(wù)的運營狀況適時的選擇不同的云服務(wù)。

3. 本地升級場景

通過UCloud云平臺的在線遷移方法，可以實現(xiàn)用戶在無感知的情況下，將用戶虛擬機遷移到一個升級過的新虛擬化運行環(huán)境中，在避免中斷用戶業(yè)務(wù)的前提下，實現(xiàn)對虛擬化組件的性能優(yōu)化、故障修復(fù)以及新功能上線等軟件升級。然而在線遷移需要遷移用戶的磁盤鏡像數(shù)據(jù)，這部分花費時間占遷移時間的絕大部分。

特別是大磁盤用戶，進行一次跨機在線遷移所需的時間往往需要花費數(shù)小時。而且線上運行著大量的虛擬機，如果都進行在線遷移需要花費的時間成本更是非常巨大，這使得在線遷移方法無法大規(guī)模用于用戶虛擬化環(huán)境的升級。

當前UCloud云平臺的虛擬化組件就由KVM、Qemu和Libvirt等構(gòu)成，而且大多數(shù)的軟件升級都是通過升級Qemu和Libvrit完成。由于Libvirt位于虛擬化組件的最上層，它的升級不會影響正在運行的虛擬機，而且直接可生效，無需停機和遷移就可完成。而Qemu升級以往常需要通過在線遷移才能保證無感知的升級?？紤]到磁盤遷移占遷移時間的大部分，如果能夠避免磁盤的遷移就可以大大節(jié)省軟件升級的時間。

為此，UCloud云平臺專門開發(fā)了本地?zé)徇w移方案，以完成對Qemu軟件的性能優(yōu)化、故障修復(fù)、漏洞修補以及新功能上線等升級功能。這種方法無需遷移虛擬機的磁盤，只進行內(nèi)存遷移，從而達到快速的完成軟件升級。

如圖 3‑3所示，在進行本地?zé)嵘壍臅r候，需要在本地安裝新版的Qemu_new，而原有已經(jīng)運行的虛擬機VM_old仍然為舊版Qemu_old，然后將創(chuàng)建一臺相同配置的新虛擬機VM_new，此時新建的虛擬機VM_new的Qemu版本為Qemu_new，并且新虛擬機VM_new此時處于paused狀態(tài)。

新虛擬機VM_new和舊虛擬機VM_old之間通過socket文件進行內(nèi)存數(shù)據(jù)遷移，這個遷移過程和普通在線遷移過程一致，也是先進行一次全量的內(nèi)存遷移，然后再進行多次迭代的增量內(nèi)存遷移，并最終短暫停機完成最后一次的內(nèi)存和虛擬機機器信息等遷移。

圖 3‑3虛擬機本地遷移的內(nèi)存遷移過程

當前本地?zé)徇w移方法已經(jīng)在UCloud平臺上大規(guī)模應(yīng)用，在實際使用過程中，不但具有普通在線遷移的優(yōu)點，而且整個遷移過程更加快速，基本上可以秒級完成用戶虛擬機的Qemu升級，對用戶基本沒有影響。

目前，我們已經(jīng)使用本地?zé)徇w移方法解決了多個高危安全漏洞對線上Qemu的影響。另外，通過本地?zé)徇w移方法還實現(xiàn)對線上運行Qemu版本的精簡統(tǒng)一，方便對Qemu版本的維護工作。

五、總結(jié)

綜上所述，目前UCloud虛擬化云平臺已經(jīng)對熱遷移技術(shù)進行了全方位的優(yōu)化，包括熱遷移技術(shù)各個階段的優(yōu)化(宿主機的選擇、磁盤和內(nèi)存的優(yōu)化、和網(wǎng)絡(luò)的切換設(shè)置等)、快速遷移優(yōu)化、跨存儲類型遷移優(yōu)化、甚至本地?zé)嵘墐?yōu)化等。

此外，UCloud虛擬化云平臺還提供了單獨遷移虛擬機的磁盤內(nèi)容的磁盤漂移技術(shù)、以及針對加密盤的遷移技術(shù)。這些遷移技術(shù)已經(jīng)在UCloud云平臺上廣泛用于用戶虛擬機的負載均衡、宿主機的故障處理、甚至各種虛擬化組件的在線升級等。

通過這些全方位的遷移優(yōu)化，極大的保證了用戶虛擬機的不間斷穩(wěn)定運行，有力地支撐了UCloud虛擬化云平臺的高效、彈性、高可靠性的優(yōu)點。

后續(xù)我們還將繼續(xù)對跨機熱遷移技術(shù)的高內(nèi)存負載、GPU機型、以及其他使用新型網(wǎng)卡、加速卡的特殊VM的場景進行深入開發(fā)和優(yōu)化。

【本文是51CTO專欄機構(gòu)作者“大U的技術(shù)課堂”的原創(chuàng)文章，轉(zhuǎn)載請通過微信公眾號(ucloud2012)聯(lián)系作者】

 戳這里，看該作者更多好文