在大規模云平臺的日常運營中不可避免的會存在升級或者修復宿主機的情況，如內核安全漏洞、內核、基礎軟件或驅動 Bug，甚至潛在的硬件故障和計劃性停機維護都需要宿主機進行重啟操作，導致其上的 VM 存在服務不可用的情況，如 AWS Xen Issue 導致大規模的宿主機重啟(http://aws.amazon.com/blogs/aws/ec2-maintenance-update/)。宿主機的停機維護在實踐中是一個不可避免的任務，通過內核熱補丁技術只能解決需要停機重啟的部分情況。云平臺運營商需要切實有效的技術方案來降低或比買呢宿主機的重啟問題造成的影響。

Save/Restore VM

比如AWS 在重啟大規模宿主機就利用了 Xen 的 save/restore vm 特性來避免 VM 級的重啟操作，實現用戶在短暫服務不可用時間內無需額外的上線運維操作即可服務生效。VM Save/Restore 特性實際上廣受歡迎應該是在 VirtualBox 上，通過保存 VM State 到持久化設備上來實現快速恢復 VM State 的能力，有效的避免了 VM 重啟導致的額外操作和時間。

Live Migration

（圖片來自VMWare）

熱遷移技術是目前解決宿主機重啟最通用且有效的方式，在預先計劃的系統故障或者停機維護前，通過熱遷移將宿主機上所有 VM 遷移到其他機器上并保持 VM 的可用性。KVM 的 Live Migration 就是一個典型的例子，在啟動 Live Migration 后，KVM 會在對端機器上啟動一個新的 VM 然后開啟監聽端口等待來源數據，Source VM 會將目前 VM 的瞬間內存拷貝過去，并且在接下來的內存變化會在完整內存拷貝完成進行增量傳輸。塊設備的傳輸是一個主要的問題，如果 VM 采用本地存儲，那么通過網絡來傳輸巨大的容量會成為一個非常不穩定的熱遷移失敗因素。因此，通常熱遷移需要共享存儲的支持來徹底避免塊數據傳輸使得 VM 的熱遷移可以在分鐘內完成。這樣，像 KVM 只需要將所有設備驅動(包括塊設備)和內存數據通過網絡方式傳輸到對端，可以在 ms 級別的服務不可用時間內完成遷移。具體 VM Live Migration 算法如 Pre-Copy 策略

Slave OS Hosting

因為熱遷移需要 VM 全部使用能容災的共享存儲方案，使得一些特殊性能需求的云平臺存在一定困難。云平臺共享存儲系統***的痛點之一就是 IO 延遲，因此很多云平臺會采取本地存儲加上遠端異步災備的方式來實現高性能塊存儲和高可用的折中。因為災備是異步的原因，熱遷移的塊設備遷移復雜性會大大提高，因此需要探索新的宿主機重啟并不影響 VM 的方式。這就出現了以雙系統為原型的宿主機重啟方案，本質就是每個宿主機存在兩個系統，一個主系統就是通常意義上的宿主系統，而副系統是一個只支持部分能力的 mini OS。在需要宿主機操作系統重啟恢復的時候，主系統會將硬件的抽象服務(也就是操作系統的服務)轉交給副系統提供服務，這時 VM 仍然能夠進行正常的 CPU 計算和內存服務，只是提供服務的系統從原來的主系統變成了副系統。另外，mini OS 會在一些困難的服務轉交如 IO 服務上采取妥協的方式，mini OS 會 block 或者減慢部分服務的能力。然后主系統在重載后啟動重新接管，VM 恢復正常，期間可能會造成 VM 的 IO 能力下降等等問題，但是可以保證大部分 VM 業務服務的正常運作。

小結

本文簡要介紹了目前云平臺在對不可避免的宿主機重啟處理上的優化技術，來減少用戶 VM 不可服務時間來提升云平臺的可用性。云平臺服務商通過會根據自身系統和 Hypervisor 的類型來選擇和實現特定的技術來實現這個目的。