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

前言

去年，工信部印發《推進企業上雲實施指南（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中查找，找到了進行異或運算，而後增量傳輸。若是沒找到，則要先將該頁面進行緩存（以便下次進行查找、對比），而後再完整的將該頁面傳輸到對端。

優化效果測試

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

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

二、開啓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漫談