【乾貨分享】虛擬機熱遷移性能優化

前言

去年，工信部印發《推動企業上雲實施指南（2018-2020年）》，旨在推動行業企業在生產、經營、管理中積極上雲。上雲簡而言之，就是指企業將原有IT基礎設施轉變或遷移到雲基礎設施中，而業務在雲環境中運行的邊界通常就是容器和虛擬機。虛擬機作爲一個較安全的解決方案在生產環境中得到了廣泛的應用，尤其虛擬機的熱遷移技術，作爲一個殺手級的解決方案更是在數據中心大受歡迎。原因在於，通過熱遷移技術可以在用戶無感知的情況下實現故障轉移、負載均衡和版本升級等數據中心的剛需操作。但是，在實際落地過程中往往由於現網環境的複雜性，諸如網絡帶寬壓力、服務器負載過高、業務虛擬機的體量過大、頁面刷新速度頻繁等一系列問題，導致虛擬機遷移失敗。因此本文通過介紹熱遷移的基本概念，分析瓶頸之所在，並就現有的優化技術底層原理進行剖析，依據不同業務場景進行鍼對性的優化。

1.熱遷移基本概念介紹

遷移模型

熱遷移是指將正在運行的虛擬機在不同的物理機之間進行移動，期間不能斷開來自客戶的連接。虛擬機的內存，存儲和網絡連接都從源端轉移到目的端。

圖 1‑1  遷移模型

熱遷移時通常需要遷移兩部分數據，一是當前虛擬機的內存數據，另一個是磁盤數據。現網中考慮到性能通常會使用共享存儲，且虛擬機遷移失敗大多都是由於內存數據始終遷移不完導致的。因此，本文只討論內存數據的遷移。下面就虛擬機的內存遷移過程做詳細說明。

遷移過程

內存遷移的過程有兩種實現方式，分別是pre-copy和post-copy，鑑於官方默認的方式是pre-copy，且post-copy遷移失敗會產生不可逆的傷害，在生產環境中風險太大而很少被採用，因此這裏只討論前者。

Pre-copy過程：

1)   開啓髒頁跟蹤 2)  拷貝所有的內存頁到目的端 3)  繼續拷貝在第2步拷貝過程中弄髒的內存頁 4)  一直重複第3步直到剩下的內存頁足夠小 5)  關閉虛擬機 6)  拷貝剩下的內存頁和虛擬機狀態信息 7)  在目的端啓動這個虛擬機

圖 1‑2  遷移過程^[1]

由於遷移的過程中虛擬機不關機，所以會出現原來的內存都遷移完了，但是新的內存頁又隨之產生的情況；或者原來的內存頁被修改，這部分內存頁面需要重新傳輸。如果頁面產生或者修改的過於頻繁，並且長時間持續這種狀態，會導致髒頁源源不斷，無窮匱也。

瓶頸

可以看到，上述過程的關鍵在於第3步，即持續的拷貝弄髒的頁面直到剩下的內存頁足夠小，小到可以在下一次一次性傳輸完。可問題的關鍵就在於髒頁產生速度太快導致每個下一次都傳輸不完，遷移過程就一直耗在這裏，最終超時->中斷遷移過程->遷移失敗！

可見，熱遷移的瓶頸在於：髒頁的產生速率 > 數據傳輸速率。

2.優化方案

找準缺口，頑石可破。既然已經知道瓶頸所在，那麼解決這個問題的方法就有兩個，一則增大網絡的傳輸速率（如使用萬兆網卡），二則是減小髒頁的產生速度。但即便是萬兆網卡，只要虛擬機寫操作夠密集，且帶寬資源還要分配給其他業務，總會出現部分髒頁來不及傳送的情況。因此在儘可能提供良好傳輸環境的前提下，還要同時從數據如何最小化傳輸這個方向發力，兩手都要硬，兩手都要抓。只要優化得當，理想情況下即便是低速設備也能完成高髒頁率的遷移任務！目前就後者（減少數據生成速率）進行展開討論，這裏介紹兩種方法，分別是：

1)  XBZRLE

2)  auto-converge。

2.1 XBZRLE

減小髒頁產生速率，歸根結底還是爲了減少在網絡中傳輸的數據量。XBZRLE和Multi-threads的實現正是基於這個思路。這兩種方法都是對即將傳輸的數據進行壓縮處理後開始遷移。但在實現上又略有不同，限於篇幅這裏只討論XBZRLE。

原理

想減少數據量的傳輸？首先得搞清楚數據是如何在源端和目的端流動的：

圖 2‑1  默認遷移內存過程

如圖2-1，假如src端虛擬機有三個內存頁面，待全部傳輸到目標端後，由於源端又弄髒了其中一個頁面，此時，熱遷移需要把這個頁面再重傳一次，即使該頁面只有一個字節的修改。而使用了XBZRLE之後，數據又是如何傳輸的呢？

圖 2‑2  啓動XBZRLE後遷移內存過程

如圖2-2，全量內存拷貝完成之後，但凡有髒數據產生，僅傳輸新產生的髒數據，即增量傳輸。舉例說明，假如源端對一個4K的內存頁面修改了1byte，未使用該技術時，整個4K頁面需要重傳，但此時只需傳輸這 1 byte。4K和1byte，其間數據量相去4096倍之巨，性能提升自然不可與之前等量齊觀。那麼問題來了，怎麼知道一個頁面的那些內容被修改了呢？

XBZRLE（Xor Binary Zero Run-Length-Encoding），翻譯過來就是把修改後的頁面同之前傳輸過的頁面進行一個異或操作，異或的結果就是發生變化的數據塊，然後傳輸這部分差異數據到目標端，目標端接受到數據後再將它apply到對應的頁面上。具體過程如下圖所示：

圖 2‑3  XBZRLE作用原理流程圖^[2]

到這裏可能有一個疑問，既然要進行異或操作，修改前的內存頁哪兒來呢？是不是需要提前保留？

答案是：要得！爲了解決這個問題，XBZRLE中引入cache，即對原始的內存數據進行緩存，頁面傳輸前都要先在cache中查找，找到了進行異或運算，然後增量傳輸。如果沒找到，則要先將該頁面進行緩存（以便下次進行查找、對比），然後再完整的將該頁面傳輸到對端。

優化效果測試

本次測試的目的主要有兩點：

1、關閉和開啓XBZRLE算法對遷移效果的影響。

2、開啓XBZRLE算法的情況下，不同cache size對遷移效果的影響。

• 未開啓XBZRLE算法時進行熱遷移：

從測試的數據可以看出來，在髒頁率分別爲1M/s、4M/s、10M/s和20M/s時，如果沒有開啓XBZRLE，熱遷移是不會成功的。

• 開啓XBZRLE算法進行熱遷移：
  

可以看到，同樣的負載在開啓XBZRLE算法的情況下，局勢反轉，全部順利遷移。 說明在開啓XBZRLE算法的情況下進行遷移可以很大程度上提高熱遷移的成功率。 此外，順便統計了不同髒頁率的情況下遷移耗費的時間，以便在探討實驗二cache size對遷移效果的影響時做對比。如下表所示：（橫座標：每秒產生的髒頁，單位：M/s。縱標值：遷移耗費的時間，單位：s）

圖 2‑4  不同髒頁率完成遷移耗費時間統計

從統計圖表可以看到不同髒頁率下完成遷移大概需要的時間，同時也能反映出髒頁率越大，遷移完成所耗費的時間也越長。嗯，這也符合常理。

接下來看實驗二：cache size 對遷移效果的影響

由於默認的cache size爲64M，以上的測試都是在該默認設置下進行的，這裏探討在其他條件儘可能相同的情況下，對應cachesize 分別爲64M、128M、256M和512M時，完成遷移所需時間之間的關係。這裏統一設置虛擬機的髒頁率爲150M/s，測試結果如下圖（橫座標：cache size，單位：M。縱標值：遷移耗費的時間，單位：s）：

圖 2‑5 不同cache size下完成遷移耗費時間統計

從圖表可以看出兩個重要信息：

1)  cache size越大，遷移所耗費的時間越少，即遷移的效果越好。

2)  當前設置的髒頁率爲150M/s，遠大於實驗一中的髒頁率，但是遷移所需的時間卻遠遠小於實驗一，更能說明cache size對XBZRLE的加持效果。

因此，cache size的合理設置在一定情況下可以提升熱遷移的性能。看到圖表中cache size在512M時和256M幾乎沒什麼大的提升可能會有疑問，這說明就當前的虛擬機負載256M的cache size就已經完全完全夠用了。所以cache size並不是越大越好，要根據虛擬機的負載來合理分配，在遷移性能和資源消耗之間尋求一個最佳平衡。

此外，通過測試發現，爲虛擬機分配的cache size對物理服務器的影響很小，因此在遷移過程中如果觀測到cache missing過高，調整cache size時可以不用太擔心是否會對物理機造成壓力，酌情進行分配，堅持夠用、不浪費原則即可。

在弄清楚了XBZRLE算法的原理和實際優化效果後，可以根據業務場景按需進行調整。需要說明的是，該算法並不是默認開啓的，nova側提供的熱遷移僅僅提供了一個默認p2p + tunnelled的基本遷移方式，若想啓用需要指定libvirt的python接口對上提供的VIR_MIGRATE_COMPRESSED宏。該宏在解析到libvirt層時，支持兩種壓縮算法，如果不具體指定，默認即爲XBZRLE。

2.2 auto-converge 

如果說XBZRLE算法的目的是爲了減少在網絡中傳輸的數據量，那麼auto-converge則是真正從源頭上減少數據的生成。

原理

髒頁產生的速度太快造成大量頁面不能在熱遷移設定的宕機時間內完成傳輸，最終導致虛擬機遲遲不能完成遷移，auto-converge的思想就是：與其揚湯止沸，不如釜底抽薪，既然髒頁產生的速度太快了，那咱就讓它慢點！減少虛擬機vcpu的執行時間，進而達到減少髒頁產生的目的！但是減少vcpu的執行時間，減多少合適，以怎樣的策略去處理纔可以兼顧性能和靈活性是一個比較複雜的問題，現就現有的實現進行分析。

如果啓用了auto-converge功能，在遷移增量數據時，如果產生的髒頁數量超過上次傳輸的50%，默認情況下，QEmu會從削減20%的客戶機vcpu執行時間開始。迭代幾次後，如果還沒有完成遷移，它將重複削減分配給vcpu 10%的運行時間。QEmu會一直削減vcpu直至99%。保證遷移可以在最緩慢的網絡中完全完成，但代價就是虛擬機cpu性能被極大消耗。

優化效果測試

本次測試的主要目的是證明使用auto-converge的確可以提升熱遷移的成功率。

從上次的測試中知道，在沒有開啓優化特性的時，即使1M/s的髒頁率也不能遷移成功，這裏通過開啓auto-converge特性，分別在髒頁率爲1M/s, 10M/s, 100M/s的情況下測試多組數據，剔除毛刺數據後取其平均值。遷移成功的虛擬機耗費時間統計如下：（橫座標：每秒產生的髒頁，單位：M/s。縱標值：遷移耗費的時間，單位：s）

圖 2‑6 不同髒頁率下完成遷移耗費時間統計

圖表2‑6 中可以看出，即便髒頁率達到100M/s，依然能夠遷移成功，說明該功能確實可以提升熱遷移的成功率。

此外，通過對比還可以發現，在同一髒頁率下，使用auto-converge完成遷移所耗費的時間要遠低於XBZRLE。但是在生產環境中我們不推薦按使用該特性，尤其應該避免在CPU和IO密集型的虛擬機上使用，因爲auto-converge會不斷降低被遷虛擬機的vcpu運行時間，因此可能會造成IO請求延遲，丟包甚至無響應的情況，影響用戶體驗，甚至正常的業務運行。

3.總結

雖然上述提到的優化特性都能夠極大提升熱遷移的效率，但是即便使用上述的優化手段也依然無法避免在一些大規格，高負載的場景下面臨遷移失敗的囧境。因此，完美的技術是不存在的，任何技術都有缺陷，不可能cover的了所有應用場景。譬如上述XBZRLE壓縮算法，當一個頁面的數據修改超過半數以上時，很明顯這種算法帶來的優勢已經被壓縮過程本身給榨乾殆盡了；抑或當一個頁面改動的數據比較小但是多且分散時，極端的例子比如每隔幾個字節修改一兩個字節，這種場景下XBZRLE就力不從心了。所以，熱遷移過程中沒有一勞永逸的解決方案，應該根據業務場景具體分析、靈活搭配、最大化釋放各優化特性的潛力。

4.後續

上述介紹的熱遷移方案主要應用於負載均衡和故障轉移場景下，他們有一個共同點就是：虛擬機需要跨物理節點，這意味着虛擬機遷移時數據需要跨網絡傳輸。文章開頭我們提到生產環境中熱遷移的另一個重要應用場景就是新功能上線或虛機版本升級，這種情況下熱遷移會長時間擁塞網絡帶寬，這並不是用戶所期待的，也不是作爲一個有追求的技術人員應該視而不見的！因此，針對這種場景後續我們會推出本地熱遷移的解決方案：虛擬機無需跨物理節點、無需佔用網絡、僅依靠unix socket在本地進行數據的傳輸，可以數十倍縮短遷移時間，提升遷移效率。給批量、自動化遷移帶來極大的可能性。拭目以待吧! 

參考文獻

[1]  http://www.slideshare.net/yamahata/yabusame-postcopy-live-migration-for-qemukvm?from_m_app=android

[2]  https://www.slideshare.net/blopeur/enhancing-live-migration-process-for-cpu-andor-memory-intensive-vms-running-enterprise-application-s

往期精選

1	【大雲製造】爲雲而生 - 大雲BEK內核
2	【乾貨分享】BC-MQ大雲消息隊列高可用設計之談
3	【乾貨分享】Kubernetes容器網絡之CNI漫談