熱遷移的原理

當一個運行中的虛擬機在不同計算節點中進行移動的時候，對于用戶的應用程序來說主要涉及到 CPU 和內存的運行狀態，CPU 狀態的拷貝幾乎是可以瞬時完成的，而由于內存的特性，其在遷移過程中已經拷貝的內存也會面臨被重寫的情況，所以在整個虛擬機遷移過程中，內存遷移需要消耗較長的時間。

在這篇文章中，我們主要介紹一種最常見的內存拷貝策略：預拷貝策略（Pre-Copy）。

簡單來說，預拷貝策略主要分為三個階段：

? Init Copy：將所有內存頁標記為 Dirty Page（臟內存），并將其拷貝到目標主機上，此時虛擬機管理器繼續監視虛擬機的內存變化情況

? Iterative Pre-Copy：重新計算新產生的臟內存，并進行迭代，將被修改的內存頁拷貝到目標主機上，直到滿足條件退出

? Stop-and-Copy：停止運行源主機的 GuestOS，將剩余的臟內存以及設備狀態信息遷移到目標主機上，并啟動虛擬機

ArStack 的探索與實踐

根據第一性原理（First Principle），我們不難發現在虛擬機進行熱遷移的過程中， Iterative Pre-Copy 是最重要的階段，所以 ArStack 幾乎所有的優化工作都是圍繞這一階段展開的。

超時參數的調整

在過去的一些反饋中，大規格的虛擬機（如128G內存）在承受中高強度的負載時往往會在遷移中產生瓶頸，經過研究相關案例后我們發現該問題主要是由于遷移時間超時導致的，由于網絡帶寬、內存量等因素的限制，這類虛機往往需要更長的遷移時間，所以針對這類情況我們按需調整了遷移超時的參數，以提升該場景下的遷移成功率。

最大停機時間的調整

還記得上面我們講到的在 Iterative Pre-Copy 階段中“直到滿足條件退出”么，最大停機時間（Max Downtime）就是 Nova 選擇退出的條件之一，在每次迭代中 Libvirt 都會重新計算虛擬機新產生的臟內存以及每次迭代需要耗費的時間，再根據當前帶寬和臟頁數計算出傳輸剩余數據的時間，即Downtime。

如果Downtime 在管理員配置的 Live Migration Max Downtime 范圍之內，則退出，進入到 Stop-and-Copy 階段。

在與業務團隊溝通后，我們進行了大量的實驗與驗證，最終提供了一套更為合理的參數配置，該參數的調整明顯提升了熱遷移的成功率。

VM 級的內存收斂

需要注意的是，最大停機時間并不是如同殺手锏的存在，如果虛擬機持續處于高負載狀態，即不斷產生大量的臟內存，Downtime 有可能一直無法進入我們預設的范圍，此時的 Iterative Pre-Copy 就如同《開端》里的李詩情一樣，不斷在進行循環。

現在，內存自動收斂（Auto Converge）就要作為“銀色子彈”登場了。

開啟 Auto Converge 后，當進行熱遷移時，Qemu 會降低虛擬機的運行速度，從而減少內存寫入的操作，這樣使得 Dirty Page 生成的速度降低，同時 Auto Converage 有一套自身的算法，會不斷增加對 vCPU 的限制（上限為99%），直到遷移成功。

OpenStack 自身提供了平臺級的內存收斂能力，ArStack 修改了社區代碼的相關邏輯，為用戶提供了顆粒度為虛擬機級的內存收斂能力，用戶可以針對單臺虛機進行相應的設置，從而獲得更加靈活、高效的遷移體驗。

VM 級的 Qos 設置

對于一些業務敏感型用戶來說，他們希望在獲得高效遷移能力的同時又能盡可能降低因為熱遷移對業務系統產生的影響。

能夠限制熱遷移的遷移速度便顯得至關重要，Live Migration Bandwidth 是遷移期間要使用的最大帶寬，默認值為0，意味著不限制遷移帶寬。

ArStack 同樣為用戶提供了顆粒度為虛擬機級的 Qos 配置，以便于用戶能夠自主評估并控制遷移的速度。

多線程遷移

在獲得了國產化團隊的支持后，ArStack 整合并提供了全局范圍內的多線程遷移能力，在默認狀態下，ArStack 會為所有參與遷移任務的 VM 開啟多線程遷移的選項，當 Libvirt 接收到來自 ArStack 傳遞的信號后，會通過多個網絡連接將內存頁發送至目標主機，以提升遷移性能。

總結

作為虛擬機生命周期管理的重要組成部分，ArStack 經過數個版本的迭代，持續對熱遷移進行了大量的優化工作，以提升用戶的基礎體驗。

不僅如此，ArStack 還完善豐富了多種復雜場景下的熱遷移能力，相信在不久的將來會與用戶見面。