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

Save/Restore VM

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

Live Migration

（圖片來自VMWare）

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

Slave OS Hosting

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

小結(jié)

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