虛擬化在線遷移優化實踐（一）：KVM虛擬化跨機遷移原理
前言
當前，云計算技術的飛速發展對企業降低IT投入成本、減少系統運維開銷、加速業務交付速度、動態調整業務規模以及保障業務可靠性具有重要意義。
目前，云計算帶來的這些好處依賴于底層虛擬化技術將服務器資源虛擬出多份可供用戶使用的計算資源，從而方便云計算提供商為企業用戶提供高效、彈性、高可靠和可維護的底層IT基礎架構。其中，虛擬機在線遷移技術正是構建虛擬機技術上述優點的重要組成部分，該技術可以簡化系統維護復雜度、實現業務負載均衡、優化服務器能源消耗并增強云計算可靠性。
作為國內領先的公有云服務提供商，UCloud對其云平臺在線遷移方案進行了深入的優化，通過實踐證明這些優化能夠很好的應對線上各種遷移場景，為用戶業務的穩定與可靠提供了重要保障。
原理
在線遷移技術的本質就是在虛擬機不停機的情況下，不同物理機之間進行在線跨機遷移。首先是在目標物理機建立相同配置的虛擬機，然后進行各類數據遷移，最終快速切換到目標端新虛擬機。由于整個遷移過程中，絕大多數時間內用戶虛擬機都能保持正常運行，且***階段的切換過程非常短暫，不會造成用戶業務中斷，對用戶運行在虛擬機中的業務幾乎沒有影響，因此在線遷移技術在實現云平臺資源動態調整以及故障處理方面具有重要意義。
因為云計算平臺除了核心的底層虛擬化技術外，還包括SDN網絡、分布式存儲和運維管理系統等，所以在線遷移方案不僅要包括跨機遷移技術本身，還包括遷移前后虛擬機的管理信息以及網絡和磁盤配置信息的切換等工作。為此，本文將在線遷移過程劃分為三個階段：準備階段、遷移階段和切換階段。
考慮到UCloud云計算平臺采用KVM虛擬化技術實現虛擬化底層方案，同時共享存儲的在線遷移僅是非共享存儲的一個特例，因此本節將以非共享存儲為例，詳細介紹UCloud底層KVM虛擬化技術如何進行虛擬機的在線遷移。其中，遷移環境為虛擬化底層KVM+Qemu、虛擬化管理Libvirt、虛擬化網絡Openvswitch。
假設將源物理機SourceHost的一個虛擬機VM 遷移到目標物理機DestHost，非共享存儲虛擬機在線遷移過程的具體步驟如下：
準備階段
Step.1 選擇一臺具有足夠磁盤和內存資源的物理機DestHost，并在DestHost上創建VM對應的系統盤和數據盤，同時選定接收遷移數據的tcp端口(如圖 1-1所示)，這兩個磁盤在DestHost和SourceHost上的路徑必須完全一致。不同的是，DestHost上初始創建的只是空盤，上面沒有真實數據。
圖 1-1 在目標端新建虛擬機鏡像
Step.2 通過虛擬化管理軟件Libvirt在DestHost上創建一個和VM同樣配置的虛擬機VM’，系統盤和數據盤使用Step.1中創建的系統盤和數據盤(如圖 1-2所示)。VM’當前是paused狀態，虛擬機VM’的vcpu處于暫停狀態，同時虛擬機VM’會通過監聽一個內網的tcp端口來接收遷移數據。
圖 1-2 在目標端創建新虛擬機
遷移階段
Step.3 虛擬化管理層Libvirt給VM對應的Qemu進程發出一個遷移指令，并指定參數，例如指定DestHost為目標、需要遷移塊設備、***停機時間、遷移帶寬限制等，然后遷移數據就會通過指定tcp鏈路傳輸給DestHost上的VM’。需要注意，遷移數據的網絡包不是經過 vswitch，而是直接從SourceHost的ethx網卡出，進到DestHost的ethx，因為VM’對應Qemu進程正作為DestHost一個用戶態進程，監聽在ethx對應的內網ip(如圖 1-3所示)。
圖 1-3 虛擬機遷移數據
Step.4 經過前面三步，虛擬機的數據就正式開始遷移，剩下的挑戰是如何保證數據遷移的一致性，因為此時VM處于運行狀態，里面時刻發生內存更新、磁盤io操作和設備狀態變更，而VM’是paused狀態，只通過一個線程接收VM進程發過來的數據。
為此，在遷移過程中各種數據如何有序遷移?首先，Libvirt會發送qmp_dirve_mirror命令來通知Qemu進行虛擬機磁盤數據遷移，從而在源端和目標端直接同步磁盤數據。然后，Libvirt會再次發送qmp_migrate命令通知Qemu進行虛擬機內存數據遷移，進一步完成虛擬機主要數據的遷移。***，由于設備狀態對應的數據量很少，在遷移***階段會通過一次性同步，將Qemu里每個設備注冊的狀態同步到目標端。
另外，遷移過程中發生變更的數據如何遷移?如果不遷移變更的數據，那數據必然不一致，也表明遷移還不能結束，因此Qemu一般通過數據遷移準備、數據遷移、數據遷移收尾三個步驟來完成。
循環調用磁盤和內存遷移函數也是按階段來分別調用的。首先，循環調用磁盤和內存遷移函數的遷移數據準備功能，即前期準備工作，例如把磁盤按block為單位組織成一個數組，并設置記錄臟塊機制;把內存所有頁全部設置為臟頁，并發送開始遷移的標志到VM’的進程。
圖 1-4 全量數據遷移示意圖
緊接著，需要進行真正的數據遷移，Qemu在這個階段調用磁盤和內存遷移函數的第二步驟功能，并且要求必須等磁盤數據遷移完成后才會執行內存數據遷移。如圖 1-4所示，Qemu首先會進行磁盤(內存)的全量數據遷移，依次將每個block(頁)遷移到目標端DestHost。
圖 1-5 增量數據遷移示意圖
然后再通過多次迭代，將遷移過程中虛擬機產生的新數據遷移到目標端DestHost(如圖 1-5所示)。這一迭代過程是收斂的，收斂依據與之前設置的帶寬、***停機時間有關。同時，在迭代過程中，Qemu將邊遷移邊記錄剩下的臟數據大小，并與停機時間進行比較，如果這個值比停機時間大，那么繼續遷移，如果比停機時間小，那么源端Qemu進程就會暫停，從而避免產生新的臟數據，以便進行遷移收尾工作。
在虛擬機暫停之后，進入第三步遷移收尾工作，源端Qemu進程會把磁盤、內存臟數據和設備狀態一次性同步到目標端，完成時VM和VM’的數據將會一致。這時，上層管理軟件會把VM關閉，并把VM’的vcpu恢復運行狀態，整個虛擬機的數據遷移就完成了。
切換階段
Step.5 數據遷移完成后，VM關閉，VM’作為它的一個完全拷貝，在DestHost上運行著，但網絡還是不通的(如圖 1-2所示)。VM’通過DestHost的vswitch 連接到物理機網卡，vswitch相當于一個虛擬交換機，而VM從SourceHost遷移到DestHost，在網絡上相當于把網線從一個交換機拔下插到另一個交換機上，此時就需要一次arp廣播，告知VM的mac地址已經變更到另外一臺交換機的某個端口。
這就是遷移完成后的網絡切換，由于切換時間很短，少于tcp的超時重傳時間，因此對于原VM上跑著網絡服務程序幾乎是無感知的。此后，如圖 1-6所示，目標端DestHost虛擬機就具備和用戶直接進行交互的能力，而源端SourceHost虛擬機此時就可以刪除。
圖 1-6 完成虛擬機遷移示意圖
總結
通過以上遷移步驟，可以在KVM虛擬化平臺上實現虛擬機的跨越遷移，進而方便實現云平臺負載均衡與系統運維，并確保用戶虛擬機性能的可靠性。同時，從用戶角度來看，這個過程并不需要關心虛擬機在源端SourceHost還是目標端DestHost，但可以持續與虛擬機進行交互，整個遷移過程對用戶來說是透明的。
雖然，當前KVM虛擬化在線遷移能夠滿足大多數情況下的用戶虛擬機遷移，但還存在以下問題：
- 在磁盤和內存負載高的情況下，存在遷移無法完成的情況;
- 跨機遷移存在網絡中斷時間長的問題;
- 跨存儲類型的場景下如何進行遷移;
- 如何應用遷移進行虛擬機組件的更新。
【本文是51CTO專欄機構作者“大U的技術課堂”的原創文章，轉載請通過微信公眾號(ucloud2012)聯系作者】
