一、前言

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

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

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

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

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

1. 準(zhǔn)備階段

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

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

2. 遷移階段

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

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

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

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

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

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

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

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

由于UDisk是網(wǎng)絡(luò)塊存儲(chǔ)，在遷移一臺(tái)帶有UDisk機(jī)器時(shí)， 遷移UDisk盤(pán)是沒(méi)有必要的，因?yàn)檫@個(gè)盤(pán)可以通過(guò)網(wǎng)絡(luò)掛到目標(biāo)。為此，我們?cè)谶w移時(shí)過(guò)濾掉虛擬機(jī)的UDisk盤(pán)，同時(shí)對(duì)UDisk產(chǎn)品做了改造，支持多點(diǎn)掛載，這樣就解決了這個(gè)問(wèn)題，提高了遷移的效率。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、切換階段

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

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

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

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

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

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

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

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

1. 快速遷移場(chǎng)景

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

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

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

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

圖 3‑1遠(yuǎn)程拉取磁盤(pán)數(shù)據(jù)示意圖

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

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

2. 跨機(jī)型場(chǎng)景

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

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

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

為此，在進(jìn)行這種特殊跨存儲(chǔ)遷移時(shí)，需要通過(guò)Libvirt的特殊配置，先在目標(biāo)端建立一個(gè)不同存儲(chǔ)類(lèi)型的虛擬機(jī)(其他配置完全一樣)，然后再進(jìn)行后續(xù)數(shù)據(jù)遷移。

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

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

圖 3‑2跨機(jī)型遷移的存儲(chǔ)格式變換示意圖

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

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

3. 本地升級(jí)場(chǎng)景

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

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

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

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

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

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

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

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

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

五、總結(jié)

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

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

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

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

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

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