友情提示：全文1000多文字，預計閱讀時間5分鐘
前言
在當下萬物互聯的浪潮下，無論企業還是個人，數據上雲已經進行的如火如荼。5G+移動雲產品新功能也在不停地迭代發佈上線，其中有些產品能力依賴底層虛擬化組件的新功能新特性，比如保證在不中斷用戶業務的情況下達到虛擬化組件在線升級的目的，爲雲上產品新功能成功上線提供助力。
面臨的問題
目前主流的解決方案是使用虛擬化熱遷移技術，但是雲環境中虛擬機的熱遷移存在遷移週期長，成功率低，運維工作量巨大的問題，因爲目前虛擬機的熱遷移技術（libvirt層）僅僅侷限於異地遷移，即將虛擬機從一臺物理服務器遷移到另一臺遠端的物理服務器，這樣帶來的問題就是：
虛擬機的所有數據要通過網絡進行傳輸，給線上網絡帶寬帶來很大壓力
當網絡帶寬成爲遷移的瓶頸時，高負載虛機無法完成傳輸導致遷移失敗
針對以上問題，社區主要從減少數據的生成和壓縮傳輸數據兩個方向進行了優化，但是對於帶寬受限，負載極高的虛機來說，效果基本看不見。就現有環境測試來看，髒頁達到250M/s左右時，即便各種優化特性全開，也難逃遷移失敗的命運。
因此，面對雲上版本升級的迫切訴求：
突破帶寬限制，無視虛機負載，儘量保證100%成功遷移
保證遷移成功的同時，大大縮短遷移時間，以減輕運維負擔
考慮到版本升級的特殊性（不同於負載均衡必須跨節點），如果有一種方法可以在本地就能完成虛機的版本升級，那麼文章開頭提到的由於跨節點而帶來的各種問題都可以完美解決。
我們的方案
通過調查發現libvirt社區曾經有開發者提議是否引入本地熱遷移技術的支持，最終討論的結果是本地遷移需要libvirtd同時納管兩個完全相同的虛擬機，會產生很多資源衝突和腦裂（brain split）的問題，因此拒絕實現該功能。
鑑於此，通過前期調研，在沒有相關儲備知識的情況下，梳理遷移過程的每一個細節，制定了詳細的開發流程並嚴格執行，克服遇到的一個又一個技術問題，最終設計並實現了我們大雲自己的本地熱遷移技術，架構如下：
圖（1）本地熱遷移架構圖
通過該技術，當某個物理節點需要實現虛擬機版本升級時，首先直接升級qemu版本，然後對存量的虛擬機在本節點進行遷移，完成後所有的虛擬機都進入高版本。這尤其對於bug修復，新功能上線來說非常有用，而且相對於熱補丁技術的重啓失效，這是一個持久化的解決方案，並且幾乎沒什麼限制。
同時，本地熱遷移還順帶解決了另一個問題：非共享存儲的磁盤數據遷移。
在跨機遷移中，如果虛擬機的磁盤使用的是本地磁盤，那麼就不止要遷移內存數據，磁盤也要一起遷。而當下虛擬機的磁盤動輒幾百GB甚至上TB，真要遷，可能得耗時達數小時之久，費機器不說，還費運維人員。
有了本地熱遷之後，這個問題也就不再是個問題了。
性能表現
本地遷移效果怎麼呢？來看一組數據：
規格 |
負載 |
遷移時間 |
丟包（1s） |
2vcpu 64G |
1GB/s dirty page |
< 1min |
無 |
表（1）本地熱遷移高負載虛機性能表現
同樣的環境下，如果是跨機遷移，髒頁1GB/s的負載是100%失敗的。即便這個負載再降四分之三，可能半盒煙都抽完了還沒遷過去，但如果用本地熱遷，你拿根兒煙出來點個火就已經遷完了。這就是差距。
總結
本地遷移技術的優點：
在本地遷，不佔用網絡帶寬，避免了網絡波動擠壓其他業務正常運行
遷移速度快，高負載的虛機也能實現秒級遷移，意味着幾乎100%成功率
非共享存儲的情況下，避免了磁盤數據的拷貝，節省大量時間
本地熱遷移技術將在BC-Linux 7.5 libvirt 3.9.0開始支持，之前因爲線上版本衆多且版本跨度太大、互相遷移各種異常問題頻發、數萬臺節點升級耗時數月之久的日子一去不復返了。現在可以快速拉平資源池版本，在大大減小運維人員壓力的同時給數據中心軟硬件升級帶來更大的靈活性和選擇性，也給客戶帶來更快捷的問題響應速度。
-End：）
往期精選
1、乾貨分享 | E-RocketMQ大雲消息隊列消息軌跡設計與實現
2、乾貨分享 | 堵塞 VS非堵塞REST服務在Spring MVC中的性能測試對比
