在遷移過程中我們需要解決以下幾個問題：
宿主機的選擇歇由；
磁盤鏡像處理废恋；
網(wǎng)絡切換設(shè)置氧秘；
內(nèi)存磁盤壓力的處理等讳苦。
普通遷移優(yōu)化
準備階段
在遷移準備階段楣铁，需要選擇相同業(yè)務類型的宿主機癌瘾，以便方便創(chuàng)建相同配置的虛擬機。該機型除了具有足夠空閑內(nèi)存和磁盤的物理機外，還需要考慮目標物理機的配置是否合適钝域。特別是需要考慮CPU的型號和內(nèi)核的版本號讽坏。
另外，考慮到遷移過程網(wǎng)絡帶寬有限例证，如果帶寬被其他任務占用路呜，就會使得遷移速度下降，甚至影響最終遷移的成功率织咧。為此胀葱，除非物理機之間的網(wǎng)絡帶寬足夠大，原則上并不允許在相同兩臺物理機之間進行多個并行的遷移任務笙蒙，以便盡量確保在線遷移的成功率抵屿。
遷移階段
在線遷移過程中需要遷移虛擬機的所有磁盤和內(nèi)存數(shù)據(jù)，而且虛擬機在遷移過程中并不停機手趣，這使得需要遷移更多的增量數(shù)據(jù)晌该。如果能夠減少數(shù)據(jù)的遷移量，就能夠減少遷移時間绿渣，從而更快的實現(xiàn)云平臺的資源動態(tài)調(diào)整和故障處理朝群。
磁盤在物理機上是以文件方式存在的，這個文件是sparse文件中符，假設(shè)虛擬機的磁盤是100G姜胖，但實際使用了10G，那么這個磁盤文件在物理機上只占用了10G空間淀散。如圖 2?-1所示右莱，但是原生的Qemu在遷移磁盤時并沒有保持sparse特性，所以這個100G的磁盤遷移到目標物理機上后就實際占用了100G空間档插。這個對物理機的磁盤空間來說是非常浪費的慢蜓，而且還嚴重影響遷移的完成時間。
如圖2-2所示郭膛，在源端讀到全0的塊晨抡，就不發(fā)送到目標端，這樣目標端就是跳著塊來寫一個文件则剃，這樣就保持了磁盤文件的sparse特性耘柱。同時，考慮到線上往往存在多種Qemu版本棍现，還要考慮到原生的Qemu和打了這個patch的Qemu之間遷移機器如何保持sparse调煎。為此，可以通過在Qemu中接收磁盤數(shù)據(jù)過程判斷一個塊是否全部為0己肮，如果是就不實際寫磁盤士袄，即可解決悲关。所有的零塊數(shù)據(jù)都被跳過，不進行傳輸娄柳。
通過上述方法就可以忽略磁盤遷移過程中的零數(shù)據(jù)坚洽，大大減少傳輸?shù)臄?shù)據(jù)量。最終西土，通過Qemu的這些patch，還可以明顯減少在線遷移的數(shù)據(jù)傳輸量和鏡像文件的空間占用量鞍盗。
存儲盤優(yōu)化需了。直接進行掛載卸載操作。不需要創(chuàng)建新盤進行數(shù)據(jù)copy般甲。直接將盤轉(zhuǎn)移過去肋乍。
遷移結(jié)束優(yōu)化
如果用戶產(chǎn)生的臟內(nèi)存數(shù)據(jù)過多，就會使得遷移的增量數(shù)據(jù)傳輸時間一直大于最大停機時間敷存，使得增量傳輸階段不斷進行循環(huán)迭代墓造，導致整個遷移過程無法完成
由于用戶產(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ā)自動auto-converge功能。該功能默認情況下宙址，將削減20%的虛擬機vCPU執(zhí)行時間轴脐，也就減低用戶虛機vCPU的執(zhí)行速度，并減少新增的臟數(shù)據(jù)曼氛。
在每次內(nèi)存迭代開始時豁辉，它會根據(jù)之前的削減情況，決定后續(xù)削減粒度舀患。如果新增臟數(shù)據(jù)仍然過多徽级，它將重復削減10%的許可vCPU的運行時間，直至削減CPU直至99%聊浅，從而觸發(fā)最后階段的停機遷移餐抢，以完成遷移過程现使。
雖然這種優(yōu)化會使得虛擬機的停機時間稍長，但是根據(jù)長期實踐結(jié)果旷痕，整個遷移的停機時間仍然非常刑夹狻（小于100ms），因此這項優(yōu)化對提高遷移的成功率有重要意義欺抗。
壓縮遷移優(yōu)化
雖然Qemu的auto-converge功能可以在一定程度上解決用戶內(nèi)存負載對遷移的影響售碳，提高遷移成功率，但如果用戶產(chǎn)生的臟數(shù)據(jù)對vCPU的執(zhí)行速度依賴不大绞呈，則會使遷移的增量數(shù)據(jù)傳輸時間一直大于最大停機時間贸人，使整個遷移過程無法完成〉枭考慮到內(nèi)存負載高的用戶艺智，往往會反復修改某一內(nèi)存頁，這些內(nèi)存頁面很容易被壓縮圾亏。為此十拣，可以考慮在遷移內(nèi)存數(shù)據(jù)前進行壓縮。
如圖 2-4所示志鹃，當前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)存遷移速度直撤。
實際使用表明通過這種壓縮方法可以提高高內(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ōu)點在于不能因為遷移失敗而導致虛擬機關(guān)機，不管成功或者失敗岗宣，都要保障虛擬機實例的存活（源端或目標端）蚂会。
2. OVS切換優(yōu)化
此外，我們在遷移過程中觀察到耗式，在遷移即將完成時存在數(shù)秒網(wǎng)絡中斷的情況胁住，這會導致用戶業(yè)務出現(xiàn)短暫中斷，使得后臺的遷移過程對用戶不透明刊咳。而且為減少對用戶業(yè)務造成不利影響措嵌，往往需要事先和用戶協(xié)調(diào)溝通遷移事項，限制了在線遷移的應用芦缰。
為此，通過大量的測試遷移實驗發(fā)現(xiàn)最后一輪的虛擬機的遷移關(guān)機時間downtime基本在70ms左右枫慷，并不是長時間網(wǎng)絡中斷的主要原因让蕾，而且虛擬機內(nèi)部壓力和遷移速度的變化對遷移downtime并無明顯影響。虛擬機網(wǎng)絡是采用openswitch來定義組建的或听，經(jīng)過大量實驗確認遷移過程中的網(wǎng)絡中斷時間和openswtich設(shè)置目標端虛擬機新flow規(guī)則的延時時間存在正相關(guān)關(guān)系探孝。
在虛擬機遷移后到目標端DestHost后，及時為虛擬機下發(fā)的新flow規(guī)則誉裆。通過優(yōu)化openswtich的網(wǎng)絡配置機制顿颅，目前已經(jīng)將遷移過程中的網(wǎng)絡中斷時間控制在幾百毫秒左右，基本做到用戶無感知足丢，不會因為在線遷移造成用戶業(yè)務的中斷粱腻。
如果用戶虛擬機正在運行高IO負載業(yè)務，會導致磁盤遷移過程遲遲無法結(jié)束斩跌，最終導致遷移失敗绍些。
如圖 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)步驟如下：
通過快速遷移優(yōu)化冰更，整個完整的遷移過程所需的時間，和傳統(tǒng)的遷移方法所需的時間相當昂勒。但是遷移過程中蜀细，共享存儲遷移的過程非常短暫，可以快速的在目標端DestHost上拉起虛擬機VM戈盈，迅速降低源端SourceHost的負載奠衔，改善用戶VM之間的資源競爭，改善用戶VM的性能，特別對于具有大數(shù)據(jù)盤的VM用戶具有重要意義恶耽。
司训，在進行這種特殊跨存儲遷移時，需要通過Libvirt的特殊配置脏里，先在目標端建立一個不同存儲類型的虛擬機（其他配置完全一樣），然后再進行后續(xù)數(shù)據(jù)遷移虹曙。
如下圖 3?-2所示迫横，通過這種特殊配置之后，源端Qemu將通過qcow2驅(qū)動從qcow2磁盤文件中讀取客戶磁盤數(shù)據(jù)酝碳，再通過網(wǎng)絡發(fā)送到目標端矾踱，目標端Qemu在接收到數(shù)據(jù)之后，通過raw驅(qū)動將數(shù)據(jù)寫入到lvm塊設(shè)備中疏哗。
通過多次的反復迭代最終完成整個磁盤的遷移呛讲，并最終將源端普通云主機上的用戶虛擬機遷移切換到目標端SSD機型的云主機上。整個遷移過程對用戶是透明的返奉，不會對用戶業(yè)務造成不利影響贝搁，即便目標端虛擬機遷移失敗也不會影響源端用戶虛擬機的正常運行。
由于Libvirt位于虛擬化組件的最上層芽偏，它的升級不會影響正在運行的虛擬機徘公，而且直接可生效，無需停機和遷移就可完成哮针。而Qemu升級以往常需要通過在線遷移才能保證無感知的升級关面。考慮到磁盤遷移占遷移時間的大部分十厢，如果能夠避免磁盤的遷移就可以大大節(jié)省軟件升級的時間等太。
如圖 3-3所示，在進行本地熱升級的時候蛮放，需要在本地安裝新版的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)存和虛擬機機器信息等遷移佃迄。
