?

熱遷移(Live Migration)在云計(jì)算中是如同黑魔法一般的存在，它可以使用戶在無(wú)感知的情況下將虛擬機(jī)從一臺(tái)物理服務(wù)器遷移到另一臺(tái)物理服務(wù)器上，且整個(gè)遷移過(guò)程中應(yīng)用程序幾乎不會(huì)發(fā)生中斷，是保障 SLA 的利器。本期智匯華云將從熱遷移的原理出發(fā)，為大家揭曉 ArStack 團(tuán)隊(duì)為持續(xù)優(yōu)化熱遷移能力進(jìn)行的探索與實(shí)踐。

熱遷移的原理

當(dāng)一個(gè)運(yùn)行中的虛擬機(jī)在不同計(jì)算節(jié)點(diǎn)中進(jìn)行移動(dòng)的時(shí)候，對(duì)于用戶的應(yīng)用程序來(lái)說(shuō)主要涉及到 CPU 和內(nèi)存的運(yùn)行狀態(tài)，CPU 狀態(tài)的拷貝幾乎是可以瞬時(shí)完成的，而由于內(nèi)存的特性，其在遷移過(guò)程中已經(jīng)拷貝的內(nèi)存也會(huì)面臨被重寫的情況，所以在整個(gè)虛擬機(jī)遷移過(guò)程中，內(nèi)存遷移需要消耗較長(zhǎng)的時(shí)間。

在這篇文章中，我們主要介紹一種最常見的內(nèi)存拷貝策略：預(yù)拷貝策略(Pre-Copy)。

簡(jiǎn)單來(lái)說(shuō)，預(yù)拷貝策略主要分為三個(gè)階段：

Init Copy：將所有內(nèi)存頁(yè)標(biāo)記為 Dirty Page(臟內(nèi)存)，并將其拷貝到目標(biāo)主機(jī)上，此時(shí)虛擬機(jī)管理器繼續(xù)監(jiān)視虛擬機(jī)的內(nèi)存變化情況

Iterative Pre-Copy：重新計(jì)算新產(chǎn)生的臟內(nèi)存，并進(jìn)行迭代，將被修改的內(nèi)存頁(yè)拷貝到目標(biāo)主機(jī)上，直到滿足條件退出

Stop-and-Copy：停止運(yùn)行源主機(jī)的 GuestOS，將剩余的臟內(nèi)存以及設(shè)備狀態(tài)信息遷移到目標(biāo)主機(jī)上，并啟動(dòng)虛擬機(jī)

ArStack 的探索與實(shí)踐

根據(jù)第一性原理(First Principle)，我們不難發(fā)現(xiàn)在虛擬機(jī)進(jìn)行熱遷移的過(guò)程中， Iterative Pre-Copy 是最重要的階段，所以 ArStack 幾乎所有的優(yōu)化工作都是圍繞這一階段展開的。

超時(shí)參數(shù)的調(diào)整

在過(guò)去的一些反饋中，大規(guī)格的虛擬機(jī)(如128G內(nèi)存)在承受中高強(qiáng)度的負(fù)載時(shí)往往會(huì)在遷移中產(chǎn)生瓶頸，經(jīng)過(guò)研究相關(guān)案例后我們發(fā)現(xiàn)該問(wèn)題主要是由于遷移時(shí)間超時(shí)導(dǎo)致的，由于網(wǎng)絡(luò)帶寬、內(nèi)存量等因素的限制，這類虛機(jī)往往需要更長(zhǎng)的遷移時(shí)間，所以針對(duì)這類情況我們按需調(diào)整了遷移超時(shí)的參數(shù)，以提升該場(chǎng)景下的遷移成功率。

最大停機(jī)時(shí)間的調(diào)整

還記得上面我們講到的在 Iterative Pre-Copy 階段中“直到滿足條件退出”么，最大停機(jī)時(shí)間(Max Downtime)就是 Nova 選擇退出的條件之一，在每次迭代中 Libvirt 都會(huì)重新計(jì)算虛擬機(jī)新產(chǎn)生的臟內(nèi)存以及每次迭代需要耗費(fèi)的時(shí)間，再根據(jù)當(dāng)前帶寬和臟頁(yè)數(shù)計(jì)算出傳輸剩余數(shù)據(jù)的時(shí)間，即Downtime。

如果 Downtime 在管理員配置的 Live Migration Max Downtime 范圍之內(nèi)，則退出，進(jìn)入到 Stop-and-Copy 階段。

在與業(yè)務(wù)團(tuán)隊(duì)溝通后，我們進(jìn)行了大量的實(shí)驗(yàn)與驗(yàn)證，最終提供了一套更為合理的參數(shù)配置，該參數(shù)的調(diào)整明顯提升了熱遷移的成功率。

VM 級(jí)的內(nèi)存收斂

需要注意的是，最大停機(jī)時(shí)間并不是如同殺手锏的存在，如果虛擬機(jī)持續(xù)處于高負(fù)載狀態(tài)，即不斷產(chǎn)生大量的臟內(nèi)存，Downtime 有可能一直無(wú)法進(jìn)入我們預(yù)設(shè)的范圍，此時(shí)的 Iterative Pre-Copy 就如同《開端》里的李詩(shī)情一樣，不斷在進(jìn)行循環(huán)。

現(xiàn)在，內(nèi)存自動(dòng)收斂(Auto Converge)就要作為“銀色子彈”登場(chǎng)了。

開啟 Auto Converge 后，當(dāng)進(jìn)行熱遷移時(shí)，Qemu 會(huì)降低虛擬機(jī)的運(yùn)行速度，從而減少內(nèi)存寫入的操作，這樣使得 Dirty Page 生成的速度降低，同時(shí) Auto Converage 有一套自身的算法，會(huì)不斷增加對(duì) vCPU 的限制(上限為99%)，直到遷移成功。

OpenStack 自身提供了平臺(tái)級(jí)的內(nèi)存收斂能力，ArStack 修改了社區(qū)代碼的相關(guān)邏輯，為用戶提供了顆粒度為虛擬機(jī)級(jí)的內(nèi)存收斂能力，用戶可以針對(duì)單臺(tái)虛機(jī)進(jìn)行相應(yīng)的設(shè)置，從而獲得更加靈活、高效的遷移體驗(yàn)。

VM 級(jí)的 Qos 設(shè)置

對(duì)于一些業(yè)務(wù)敏感型用戶來(lái)說(shuō)，他們希望在獲得高效遷移能力的同時(shí)又能盡可能降低因?yàn)闊徇w移對(duì)業(yè)務(wù)系統(tǒng)產(chǎn)生的影響。

能夠限制熱遷移的遷移速度便顯得至關(guān)重要，Live Migration Bandwidth 是遷移期間要使用的最大帶寬，默認(rèn)值為0，意味著不限制遷移帶寬。

ArStack 同樣為用戶提供了顆粒度為虛擬機(jī)級(jí)的 Qos 配置，以便于用戶能夠自主評(píng)估并控制遷移的速度。

多線程遷移

在獲得了國(guó)產(chǎn)化團(tuán)隊(duì)的支持后，ArStack 整合并提供了全局范圍內(nèi)的多線程遷移能力，在默認(rèn)狀態(tài)下，ArStack 會(huì)為所有參與遷移任務(wù)的 VM 開啟多線程遷移的選項(xiàng)，當(dāng) Libvirt 接收到來(lái)自 ArStack 傳遞的信號(hào)后，會(huì)通過(guò)多個(gè)網(wǎng)絡(luò)連接將內(nèi)存頁(yè)發(fā)送至目標(biāo)主機(jī)，以提升遷移性能。

總結(jié)

作為虛擬機(jī)生命周期管理的重要組成部分，ArStack 經(jīng)過(guò)數(shù)個(gè)版本的迭代，持續(xù)對(duì)熱遷移進(jìn)行了大量的優(yōu)化工作，以提升用戶的基礎(chǔ)體驗(yàn)。

不僅如此，ArStack 還完善豐富了多種復(fù)雜場(chǎng)景下的熱遷移能力，相信在不久的將來(lái)會(huì)與用戶見面。

特別提醒：本網(wǎng)信息來(lái)自于互聯(lián)網(wǎng)，目的在于傳遞更多信息，并不代表本網(wǎng)贊同其觀點(diǎn)。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實(shí)，對(duì)本文以及其中全部或者部分內(nèi)容、文字的真實(shí)性、完整性、及時(shí)性本站不作任何保證或承諾，并請(qǐng)自行核實(shí)相關(guān)內(nèi)容。本站不承擔(dān)此類作品侵權(quán)行為的直接責(zé)任及連帶責(zé)任。如若本網(wǎng)有任何內(nèi)容侵犯您的權(quán)益，請(qǐng)及時(shí)聯(lián)系我們，本站將會(huì)在24小時(shí)內(nèi)處理完畢。