虛擬化在線遷移優化實踐（二）：KVM虛擬化跨機遷移優化指南
一、前言
上篇我們分析了基于KVM的虛擬化遷移技術原理，通過這種虛擬化遷移技術能夠提供很好的在線遷移解決方案。
但是考慮到云平臺環境的復雜性，以及用戶需求的多樣性，在遷移過程中我們需要解決以下幾個問題：
- 宿主機的選擇;
- 磁盤鏡像處理;
- 網絡切換設置;
- 內存磁盤壓力的處理等。
因此，UCloud云平臺需要對在線遷移過程進行多方面的優化，本篇文章將具體分析UCloud在不同應用場景下對KVM虛擬化遷移技術各個階段所做的優化。
二、普通遷移優化
1. 準備階段
在遷移準備階段，需要選擇相同業務類型的宿主機，以便方便創建相同配置的虛擬機。該機型除了具有足夠空閑內存和磁盤的物理機外，還需要考慮目標物理機的配置是否合適。特別是需要考慮CPU的型號和內核的版本號。
另外，考慮到遷移過程網絡帶寬有限，如果帶寬被其他任務占用，就會使得遷移速度下降，甚至影響最終遷移的成功率。為此，除非物理機之間的網絡帶寬足夠大，在UCloud平臺上原則上并不允許在相同兩臺物理機之間進行多個并行的遷移任務，以便盡量確保在線遷移的成功率。
2. 遷移階段
在線遷移過程中需要遷移虛擬機的所有磁盤和內存數據，而且虛擬機在遷移過程中并不停機，這使得需要遷移更多的增量數據。如果能夠減少數據的遷移量，就能夠減少遷移時間，從而更快的實現云平臺的資源動態調整和故障處理。
(1) 零數據優化：
UCloud的虛擬機使用的是本地存儲(UDisk除外)，磁盤在物理機上是以文件方式存在的，這個文件是sparse文件，假設虛擬機的磁盤是100G，但實際使用了10G，那么這個磁盤文件在物理機上只占用了10G空間。如圖 2‑1所示，但是原生的Qemu在遷移磁盤時并沒有保持sparse特性，所以這個100G的磁盤遷移到目標物理機上后就實際占用了100G空間。這個對物理機的磁盤空間來說是非常浪費的，而且還嚴重影響遷移的完成時間。
圖 2‑1磁盤文件零塊數據遷移前后示意圖
圖 2‑2 磁盤文件零塊數據遷移優化示意圖
如圖 2‑2 所示，我們的優化方案就是在源端讀到全0的塊，就不發送到目標端，這樣目標端就是跳著塊來寫一個文件，這樣就保持了磁盤文件的sparse特性。同時，考慮到線上往往存在多種Qemu版本，還要考慮到原生的Qemu和打了這個patch的Qemu之間遷移機器如何保持sparse。為此，可以通過在Qemu中接收磁盤數據過程判斷一個塊是否全部為0，如果是就不實際寫磁盤，即可解決。所有的零塊數據都被跳過，不進行傳輸。
通過上述方法就可以忽略磁盤遷移過程中的零數據，大大減少傳輸的數據量。最終，通過Qemu的這些patch，還可以明顯減少在線遷移的數據傳輸量和鏡像文件的空間占用量。
(2) UDisk網絡盤優化
由于UDisk是網絡塊存儲，在遷移一臺帶有UDisk機器時， 遷移UDisk盤是沒有必要的，因為這個盤可以通過網絡掛到目標。為此，我們在遷移時過濾掉虛擬機的UDisk盤，同時對UDisk產品做了改造，支持多點掛載，這樣就解決了這個問題，提高了遷移的效率。
在遷移前目標端DestHost會將UDisk進行掛載操作，同時遷移過程中會跳過UDisk的傳輸，當遷移結束時源端SourceHost會將UDisk進行卸載，這樣既避免對UDisk數據進行遷移，同時避免虛擬機在遷移過程中，對UDisk數據的訪問，實現遷移過程對用戶完全透明。
(3) 遷移結束優化
目前，在線遷移默認情況下它不能很好地處理內存寫密集型的虛擬機。由于在線遷移過程中，用戶虛擬機并不關機，這就使得遷移過程中用戶會不停產生新的內存臟數據。這些新增臟數據需要通過多次迭代的增量數據遷移來傳遞到目標端DestHost上，并在預期新增臟數據傳輸時間少于最大停機時間時，進行最后一次停機增量數據傳輸，然后將虛擬機切換到目標端DestHost。
如果用戶產生的臟內存數據過多，就會使得遷移的增量數據傳輸時間一直大于最大停機時間，使得增量傳輸階段不斷進行循環迭代，導致整個遷移過程無法完成。
圖 2‑3 內存遷移的auto-coverge優化
由于用戶產生臟內存數據的速度與虛擬機的vCPU被提交運行的時間有關，因此能夠減少用戶虛擬機vCPU執行時間可以阻止用戶產生過多的內存臟數據，從而讓遷移數據傳輸得以在內存臟數據產生之前的完成。
為此，我們對Qemu的auto-converge功能進行了優化，首先，我們提高了Qemu的throttling遷移速度，避免遷移速度限制遷移的完成時間。其次，我們修改了auto-converge的觸發條件。在增量遷移數據時，如果產生臟數據的量大于上次產生傳輸數據量的50%，并重復發生多次，則自動觸發自動auto-converge功能。該功能默認情況下，將削減20%的虛擬機vCPU執行時間，也就減低用戶虛機vCPU的執行速度，并減少新增的臟數據。
在每次內存迭代開始時，它會根據之前的削減情況，決定后續削減粒度。如果新增臟數據仍然過多，它將重復削減10%的許可vCPU的運行時間，直至削減CPU直至99%，從而觸發最后階段的停機遷移，以完成遷移過程。
雖然這種優化會使得虛擬機的停機時間稍長，但是根據長期實踐結果，整個遷移的停機時間仍然非常小(小于100ms)，因此這項優化對提高遷移的成功率有重要意義。
(4) 壓縮遷移優化
雖然Qemu的auto-converge功能可以在一定程度上解決用戶內存負載對遷移的影響，提高遷移成功率，但如果用戶產生的臟數據對vCPU的執行速度依賴不大，則會使遷移的增量數據傳輸時間一直大于最大停機時間，使整個遷移過程無法完成。考慮到內存負載高的用戶，往往會反復修改某一內存頁，這些內存頁面很容易被壓縮。為此，可以考慮在遷移內存數據前進行壓縮。
如圖 2‑6所示，當前Qemu支持的XBZRLE壓縮算法會將之前發送的內存頁面維護在其內存緩存區內。在遷移內存頁面時，會先查找該頁面是否在其XBZRLE緩存內，如果在緩存內，則進行異或編碼，只傳輸被壓縮后的增量數據;如果沒有，則直接傳輸內存頁面。通過這個過程可以大大減少發送內存頁面數據量，并提高內存遷移速度。
圖 2‑4內存遷移的xbzrle壓縮遷移優化
目前，UCloud的在線遷移已經使用XBZRLE進行高內存負載的遷移優化。實際使用表明通過這種壓縮方法可以提高高內存負載虛擬機的遷移成功率、并縮短遷移時間，同時CPU使用率提高也在合理范圍內;對于普通內存負載虛擬機的遷移，幾乎沒有額外的CPU使用率消耗。后續還會結合底層硬件加速卡，并適時的開啟多線程內存壓縮遷移優化。
三、切換階段
1. 源端paused優化
遷移的過程是由Qemu來具體執行，但是對于整個遷移過程的控制則是來自更上層的Libvirt。當Qemu在執行最后一步機器數據遷移切換時，兩邊的虛擬機都是處于paused狀態。后續Libvirt將關閉源端SourceHost上的被遷移虛擬機，并拉起目標端DestHost上的對應虛擬機。
在線遷移的最大優點在于不能因為遷移失敗而導致虛擬機關機，不管成功或者失敗，都要保障虛擬機實例的存活(源端或目標端)。為了加強遷移過程的保障，避免源端和目標端關機的情況出現，我們將Libvirt中遷移過程源端開關機的控制邏輯移到UCloud自身的運維管理平臺中，以便在出現遷移異常時，及時恢復源端SourceHost上的虛擬機。這個改造上線以來，多年未出現過由于遷移導致虛擬機宕機的情況。
2. OVS切換優化
此外，我們在遷移過程中觀察到，在遷移即將完成時存在數秒網絡中斷的情況，這會導致用戶業務出現短暫中斷，使得后臺的遷移過程對用戶不透明。而且為減少對用戶業務造成不利影響，往往需要事先和用戶協調溝通遷移事項，限制了在線遷移的應用。
為此，我們通過大量的測試遷移實驗發現最后一輪的虛擬機的遷移關機時間downtime基本在70ms左右，并不是長時間網絡中斷的主要原因，而且虛擬機內部壓力和遷移速度的變化對遷移downtime并無明顯影響。考慮到UCloud的虛擬機網絡是采用openswitch來定義組建的，經過大量實驗確認遷移過程中的網絡中斷時間和openswtich設置目標端虛擬機新flow規則的延時時間存在正相關關系。
因此，UCloud專門為在線遷移開發了網絡下發虛擬機新flow的接口。在虛擬機遷移后到目標端DestHost后，及時為虛擬機下發的新flow規則。通過優化openswtich的網絡配置機制，目前已經將遷移過程中的網絡中斷時間控制在幾百毫秒左右，基本做到用戶無感知，不會因為在線遷移造成用戶業務的中斷。
四、典型應用場景優化
1. 快速遷移場景
在通過上述在線遷移優化之后，UCloud平臺上的在線遷移方案已經可以達到很好遷移成功率，為保證用戶虛擬機的性能和可靠性提供了重要保障。但是，考慮到部分用戶存在大容量的數據盤，如果進行正常在線遷移，整個遷移時間非常長，無法快速降低源物理機的負載，不利于資源動態調整和故障處理。特別是如果用戶虛擬機正在運行高IO負載業務，會導致磁盤遷移過程遲遲無法結束，最終導致遷移失敗。為此，UCloud平臺針對這種場景專門進行了磁盤高負載虛擬機的快速遷移優化。
考慮到正常在線遷移在目標端DestHost上拉起虛擬機之后，需要先通過磁盤遷移來確保目標端DestHost上虛擬機訪問的磁盤數據和源端SourceHost相同。為此需要跳過磁盤遷移進行快速的遷移方案。
如圖 3‑1所示，首先就需要打通目標端DestHost和源端SourceHost之間的存儲系統，即共享兩個Host上虛擬機鏡像的磁盤數據;同時，在此基礎上進行共享存儲的跨機遷移，從而實現先進行虛擬機內存和CPU等數據的遷移，以便在目標端DestHost快速拉起虛擬機，緩解源端SourceHost的內存和CPU壓力。之后，再將虛擬機的大磁盤數據從源端SourceHost拉取到目標端DestHost。最后，刪除源DestHost和目標SourceHost直接的共享存儲。
具體快速在線遷移的具體實現步驟如下：
圖 3‑1遠程拉取磁盤數據示意圖
通過快速遷移優化，整個完整的遷移過程所需的時間，和傳統的遷移方法所需的時間相當。但是遷移過程中，共享存儲遷移的過程非常短暫，可以快速的在目標端DestHost上拉起虛擬機VM，迅速降低源端SourceHost的負載，改善用戶VM之間的資源競爭，改善用戶VM的性能，特別對于具有大數據盤的VM用戶具有重要意義。
目前，UCloud平臺的快速遷移方法已經全面上線，已經成功為眾多用戶完成快速跨機遷移，幫助用戶解決VM的性能和可靠性問題。
2. 跨機型場景
前述各種遷移方法，通常用于相同類型的云主機之間進行遷移，特別是目標端云主機和源云主機上的虛擬機配置需要完全一致。在UCloud云平臺，除了存在普通云主機機型外，還存在類似方舟機型、SSD機型等許多不同存儲類型的虛擬機，這些不同類型的云主機上所使用的虛擬機的磁盤配置并不完全相同。
當用戶存在這種機型切換要求時，以往的做法往往需要對用戶虛擬機停機進行機型類型轉換遷移，造成用戶業務中斷，不利于用戶根據不同業務需要進行不同機型切換。但是當用戶提出這種跨機型遷移需求時，往往伴隨著其關鍵業務負載無法滿足要求，或者關鍵業務需要在更加安全可靠的環境下運行，如果對關鍵業務進行停機切換往往是無法接受的，也極大的限制了云平臺的彈性擴展特性。
為了滿足用戶的業務需求進行機型升級切換，同時不停止虛擬機保證用戶業務在升級過程中繼續運行，為此UCloud專門開發了跨機型的特殊在線遷移方案。針對這種跨機型的特殊遷移，其關鍵點在于解決磁盤設備的類型轉換問題。在UCloud云平臺上，用戶虛擬機作為一個Qemu進程運行，該進程需要根據底層的磁盤鏡像類型，選用不同底層塊設備驅動進行數據讀寫。
為此，在進行這種特殊跨存儲遷移時，需要通過Libvirt的特殊配置，先在目標端建立一個不同存儲類型的虛擬機(其他配置完全一樣)，然后再進行后續數據遷移。
如下圖 3‑2所示，通過這種特殊配置之后，源端Qemu將通過qcow2驅動從qcow2磁盤文件中讀取客戶磁盤數據，再通過網絡發送到目標端，目標端Qemu在接收到數據之后，通過raw驅動將數據寫入到lvm塊設備中。
通過多次的反復迭代最終完成整個磁盤的遷移，并最終將源端普通云主機上的用戶虛擬機遷移切換到目標端SSD機型的云主機上。整個遷移過程對用戶是透明的，不會對用戶業務造成不利影響，即便目標端虛擬機遷移失敗也不會影響源端用戶虛擬機的正常運行。
圖 3‑2跨機型遷移的存儲格式變換示意圖
通過這種特殊的跨機型在線遷移，目前UCloud平臺可以實現普通云主機到SSD云主機的相互遷移，也可以實現普通云主機到方舟高可靠機型的相互遷移，甚至通過這種遷移實現底層磁盤類型的轉換，從而方便用戶根據業務需要切換不同的云主機類型，而且不需要中斷線上業務，實現云平臺的彈性和擴展性的提高。
目前，這種跨機型的遷移技術在國內云服務提供商中算是首創，大大提高用戶選擇的彈性度，有利于用戶按需根據業務的運營狀況適時的選擇不同的云服務。
3. 本地升級場景
通過UCloud云平臺的在線遷移方法，可以實現用戶在無感知的情況下，將用戶虛擬機遷移到一個升級過的新虛擬化運行環境中，在避免中斷用戶業務的前提下，實現對虛擬化組件的性能優化、故障修復以及新功能上線等軟件升級。然而在線遷移需要遷移用戶的磁盤鏡像數據，這部分花費時間占遷移時間的絕大部分。
特別是大磁盤用戶，進行一次跨機在線遷移所需的時間往往需要花費數小時。而且線上運行著大量的虛擬機，如果都進行在線遷移需要花費的時間成本更是非常巨大，這使得在線遷移方法無法大規模用于用戶虛擬化環境的升級。
當前UCloud云平臺的虛擬化組件就由KVM、Qemu和Libvirt等構成，而且大多數的軟件升級都是通過升級Qemu和Libvrit完成。由于Libvirt位于虛擬化組件的最上層，它的升級不會影響正在運行的虛擬機，而且直接可生效，無需停機和遷移就可完成。而Qemu升級以往常需要通過在線遷移才能保證無感知的升級。考慮到磁盤遷移占遷移時間的大部分，如果能夠避免磁盤的遷移就可以大大節省軟件升級的時間。
為此，UCloud云平臺專門開發了本地熱遷移方案，以完成對Qemu軟件的性能優化、故障修復、漏洞修補以及新功能上線等升級功能。這種方法無需遷移虛擬機的磁盤，只進行內存遷移，從而達到快速的完成軟件升級。
如圖 3‑3所示，在進行本地熱升級的時候，需要在本地安裝新版的Qemu_new，而原有已經運行的虛擬機VM_old仍然為舊版Qemu_old，然后將創建一臺相同配置的新虛擬機VM_new，此時新建的虛擬機VM_new的Qemu版本為Qemu_new，并且新虛擬機VM_new此時處于paused狀態。
新虛擬機VM_new和舊虛擬機VM_old之間通過socket文件進行內存數據遷移，這個遷移過程和普通在線遷移過程一致，也是先進行一次全量的內存遷移，然后再進行多次迭代的增量內存遷移，并最終短暫停機完成最后一次的內存和虛擬機機器信息等遷移。
圖 3‑3虛擬機本地遷移的內存遷移過程
當前本地熱遷移方法已經在UCloud平臺上大規模應用，在實際使用過程中，不但具有普通在線遷移的優點，而且整個遷移過程更加快速，基本上可以秒級完成用戶虛擬機的Qemu升級，對用戶基本沒有影響。
目前，我們已經使用本地熱遷移方法解決了多個高危安全漏洞對線上Qemu的影響。另外，通過本地熱遷移方法還實現對線上運行Qemu版本的精簡統一，方便對Qemu版本的維護工作。
五、總結
綜上所述，目前UCloud虛擬化云平臺已經對熱遷移技術進行了全方位的優化，包括熱遷移技術各個階段的優化(宿主機的選擇、磁盤和內存的優化、和網絡的切換設置等)、快速遷移優化、跨存儲類型遷移優化、甚至本地熱升級優化等。
此外，UCloud虛擬化云平臺還提供了單獨遷移虛擬機的磁盤內容的磁盤漂移技術、以及針對加密盤的遷移技術。這些遷移技術已經在UCloud云平臺上廣泛用于用戶虛擬機的負載均衡、宿主機的故障處理、甚至各種虛擬化組件的在線升級等。
通過這些全方位的遷移優化，極大的保證了用戶虛擬機的不間斷穩定運行，有力地支撐了UCloud虛擬化云平臺的高效、彈性、高可靠性的優點。
后續我們還將繼續對跨機熱遷移技術的高內存負載、GPU機型、以及其他使用新型網卡、加速卡的特殊VM的場景進行深入開發和優化。
【本文是51CTO專欄機構作者“大U的技術課堂”的原創文章，轉載請通過微信公眾號(ucloud2012)聯系作者】
