云計算幫助用戶降低成本的方法有很多，不過有一點可能被很多人忽略了，那就是不停機實時遷移（Live Migration）。

延伸閱讀，點擊鏈接了解 Akamai Cloud Computing

實時遷移如何幫助我們降低成本？那花樣可就多了：

• 資源動態(tài)調(diào)整：借助實時遷移功能，在不中斷服務(wù)的情況下將工作負載從一個實例遷移到另一個實例，從而根據(jù)需求動態(tài)調(diào)整資源。例如，在低峰期間，可以將工作負載從高性能實例遷移到低成本實例，以節(jié)省成本；在高峰期間則可以遷移回高性能實例以應(yīng)對需求。
• 故障恢復(fù)和容災(zāi)：實時遷移功能可以幫我們快速將工作負載遷移到備用實例，以應(yīng)對主機故障或區(qū)域性故障。通過實時遷移，可以確保服務(wù)的持續(xù)可用性，減少停機時間和業(yè)務(wù)影響，同時降低成本，因為備用實例通常會配置為低成本的冷備份。
• 定期維護：云服務(wù)提供商會定期進行基礎(chǔ)設(shè)施維護和更新，這可能會導(dǎo)致一些短暫的服務(wù)中斷。通過實時遷移功能，我們可以在維護期間將工作負載遷移到其他實例，以確保服務(wù)的連續(xù)性，并避免因維護活動而導(dǎo)致的潛在損失。
• 按需資源使用：實時遷移功能使我們能更靈活地管理資源使用情況，根據(jù)需要隨時調(diào)整實例規(guī)格和數(shù)量。根據(jù)實際需求動態(tài)調(diào)整資源，可以避免過度配置實例，從而降低不必要的成本。

總的來說，通過云實例的實時遷移功能，用戶可以更靈活地管理和優(yōu)化資源使用，根據(jù)需求動態(tài)調(diào)整實例配置，從而降低成本并提高服務(wù)的可用性和性能。

那么正在使用Linode云服務(wù)的你，是否考慮過：這種聽起來很方便的實時遷移功能，從底層的技術(shù)上來看，到底是怎么實現(xiàn)的？本文我們將深入了解這項技術(shù)背后的細節(jié)。

實時遷移的工作原理

在開發(fā)這項功能時，我們的第一步是調(diào)查QEMU如何處理實時遷移。QEMU是Linode使用的一種虛擬化技術(shù)，而實時遷移也是QEUM的一項功能。因此我們的重點是將這項技術(shù)引入Linode，而非重新發(fā)明一個類似的技術(shù)。

那么實時遷移技術(shù)到底是如何以QEMU的方式實現(xiàn)的？整個過程分為以下四步：

1. 啟動目標QEUM實例，該實例的各項參數(shù)與需要遷移的源QEUM實例完全相同。
2. 對磁盤進行實時遷移。數(shù)據(jù)傳輸過程中，對磁盤內(nèi)容進行的任何更改也會提交至目標磁盤。
3. 對內(nèi)存數(shù)據(jù)進行實時遷移。遷移過程中，內(nèi)存內(nèi)容的任何變化也會提交至目標內(nèi)存。如果這一過程中磁盤內(nèi)容也出現(xiàn)了變化，相關(guān)變化同樣會被提交至目標QEUM實例的磁盤中。
4. 執(zhí)行割接點。當QEMU確認有足夠多的內(nèi)存頁可以放心進行割接后，源和目標QEMU實例將會暫停。QEMU會復(fù)制最后幾頁內(nèi)存數(shù)據(jù)和機器狀態(tài)，機器狀態(tài)包括CPU緩存和下一條CPU指令。隨后，QEMU會讓目標開始運行，這樣目標實例就可以從源實例停止時的狀態(tài)恢復(fù)運行了。

這些步驟概括介紹了QEMU實時遷移的執(zhí)行過程。然而依然需要通過包含很多手工操作的方式來精確指定目標QEMU實例的啟動方式。此外，上述過程中的每個操作都必須在正確的時間執(zhí)行。

Linode實現(xiàn)實時遷移的方式

在分析過QEMU已經(jīng)實現(xiàn)的技術(shù)后，我們該考慮具體用怎樣的方式將其實施到Linode平臺上。

在實時遷移工作流程的第1步，需要啟動目標QEMU實例以接受傳入的實施遷移連接。在實現(xiàn)這一步時，我們最初的想法是拿到當前Linode實例的配置文件，隨后將其應(yīng)用到目標計算機。理論上這應(yīng)該很簡單，但進一步思考就會發(fā)現(xiàn)，實際情況要復(fù)雜很多。尤其是，配置文件雖然可以告訴我們Linode實例是如何啟動的，但并不一定可以完整描述啟動后的Linode實例的完整狀態(tài)。例如，用戶可以在Linode實例啟動完畢后通過熱插拔的方式連接塊存儲設(shè)備，但這種情況并不會記錄到配置文件中。

為了在目標主機上創(chuàng)建QEMU實例，必須對當前運行的QEMU實例進行剖析。我們通過檢查QMP接口的方式對運行中的QEMU實例進行剖析，該接口為我們提供了與QEMU實例布局情況有關(guān)的豐富信息，但它無法幫助我們從來賓系統(tǒng)的視角了解實例內(nèi)部正在發(fā)生的事情。例如，對于本地SSD和塊存儲，它只能告訴我們磁盤鏈接到哪里，以及虛擬磁盤連接到哪個虛擬化PCI插槽上。在查詢QMP以及檢查并分析了QEMU接口后，可以構(gòu)建一個Profile來描述如何在目標位置創(chuàng)建一個完全相同的實例。

在目標計算機上，我們將收到完整的描述信息，借此了解源實例到底是什么樣，隨后就可以在目標位置忠實重建這個實例，但此時還有一個差異。這個差別主要在于，目標QEMU實例在啟動時使用了一個選項，該選項可以讓QEMU接受傳入的遷移。

至此，實時遷移的記錄過程已經(jīng)基本結(jié)束，接下來需要看看QEMU是如何實現(xiàn)這些操作的。QEMU進程樹由一個控制進程和多個工作進程組成，其中一個工作進程負責返回QMP調(diào)用或處理實時遷移等任務(wù)，其他進程需要一對一映射至來賓CPU。來賓環(huán)境與QEMU端的功能相互隔離，具體行為類似于獨立的系統(tǒng)。

從這個意義來看，我們需要處理三層內(nèi)容：

• 第1層是管理層；
• 第2層是QEMU進程的一部分，負責處理所有操作；
• 第3層是實際的來賓層，負責與Linode用戶進行交互。

目標實例啟動并準備好接受傳入的遷移后，目標硬件會告知源硬件開始發(fā)送數(shù)據(jù)。源端會在收到這個信號后開始進行處理，并會在軟件中告知QEMU開始傳輸磁盤內(nèi)容。軟件會自主監(jiān)控磁盤傳輸進度，借此檢查傳輸操作是否完成，并會在磁盤傳輸完成后自動開始遷移內(nèi)存內(nèi)容。此時軟件依然會自主監(jiān)控內(nèi)存遷移進度，并在內(nèi)存遷移完畢后自動切換至割接模式。上述全過程都是通過Linode的40Gbps網(wǎng)絡(luò)進行的，因此網(wǎng)絡(luò)方面的操作都可以快速完成。

割接：關(guān)鍵環(huán)節(jié)

割接操作是實時遷移過程中最重要的一環(huán)，只有理解了它，才能完全理解實時遷移操作。

在割接點狀態(tài)下，QEMU已經(jīng)確認做好了所有準備，可以進行割接并在目標計算機上運行。源QEMU實例會讓兩端暫停運行，這意味著：

1. 來賓系統(tǒng)被“時?！薄Ｈ绻麃碣e系統(tǒng)正在運行時間同步服務(wù)（如NTP），NTP會在遷移完成后自動重新同步時間。這是因為系統(tǒng)時鐘會產(chǎn)生幾秒鐘的落后。
2. 網(wǎng)絡(luò)請求停止。如果網(wǎng)絡(luò)請求是TCP請求（如SSH或HTTP），基本上不會產(chǎn)生可感知的連接中斷；如果網(wǎng)絡(luò)請求是UDP請求（如流媒體視頻），可能會導(dǎo)致少量丟幀。

由于時間和網(wǎng)絡(luò)請求均已停止，我們希望割接能盡量快速完成。然而為保證成功割接，還需要進行一些檢查：

• 確保實時遷移順利完成不出錯。如果出錯則要進行回滾，解除源Linode實例的暫停狀態(tài)，不再進一步執(zhí)行其他操作。開發(fā)過程中，我們在這方面進行了大量實驗并解決了很多錯誤，雖然這為我們造成了很多頭疼的問題，但最終都順利解決了。
• 確保關(guān)閉源實例的網(wǎng)絡(luò)，并在目標實例上正確連接。
• 讓我們的其余基礎(chǔ)設(shè)施清楚得知遷移后的Linode實例是通過哪臺物理計算機運行的。

由于割接過程時間有限，我們希望能盡快完成上述操作。解決了這些問題后，即可繼續(xù)進行割接了。源Linode實例會自動會自動收到“割接完成”信號并讓目標實例運行起來。目標Linode實例會從源實例暫停時的狀態(tài)恢復(fù)運行。源和目標實例上的其余內(nèi)容則會被清理。如果目標Linode實例在未來某個時間需要再次進行實時遷移，則會重復(fù)執(zhí)行上述步驟。

CPU標記

在向來賓操作系統(tǒng)呈現(xiàn)CPU方面，QEMU有不同的選項。其中一個選項可將主機CPU的型號和功能（即CPU標記）直接傳遞給來賓系統(tǒng)。通過使用該選項，來賓即可不受約束地使用KVM虛擬化系統(tǒng)所支持的全部能力。當Linode首次采用KVM時（當時還沒有實時遷移功能），為了實現(xiàn)最大化性能，我們就使用了該選項。然而在開發(fā)實時遷移功能的過程中，該選項為我們造成了很多挑戰(zhàn)。

在實時遷移的測試環(huán)境中，源和目標主機是兩臺完全相同的計算機。但在現(xiàn)實世界中，我們的硬件集群并非100%完全相同的，計算機之間的某些配置差異可能導(dǎo)致產(chǎn)生不同的CPU標記。這很重要，因為當一個程序被載入Linode的操作系統(tǒng)后，Linode會向該程序呈現(xiàn)CPU標記，為了充分利用這些標記，程序可以將軟件中的特定部分載入內(nèi)存。如果一個Linode實例被實時遷移到不支持該CPU標記的目標計算機，程序?qū)罎?。這可能導(dǎo)致來賓操作系統(tǒng)崩潰，甚至導(dǎo)致Linode重啟動。

因此在實現(xiàn)實時遷移時，我們必須設(shè)法防止程序因為CPU標記的不匹配而崩潰?？尚械倪x項有兩個：

讓QEMU模擬CPU標記。但這可能導(dǎo)致原本快速運行的軟件運行速度變慢，并且完全無法調(diào)查原因。

收集源計算機的CPU標記列表，確保目標計算機具備完全相同的標記，隨后再進行遷移。這種方式更復(fù)雜，但不會影響用戶程序的運行速度。我們最終選擇了這種方式。

在決定對源和目標的CPU標記進行匹配后，我們使用下列兩種方法的組合最終實現(xiàn)了目標：

• 第一種方法更簡單。將源硬件的所有CPU標記發(fā)送給目標硬件，當目標硬件設(shè)置新的QEMU實例時，會通過檢查來確保自己至少擁有和源Linode實例相同的標記。如果不匹配，將不進行實時遷移。
• 第二種方法更復(fù)雜，但可以避免因為CPU標記不匹配導(dǎo)致的遷移失敗。在發(fā)起實施遷移前，我們會對具備可兼容CPU標記的硬件創(chuàng)建一個列表，隨后從該列表中選擇硬件來創(chuàng)建目標計算機。

第二種方法必須能快速執(zhí)行，并且讓我們的工作變得更復(fù)雜。某些情況下，我們需要針對超過900臺計算機檢查最多226個CPU 標記。為所有這226個CPU標記編寫檢查代碼本就很困難，而這些代碼還需要不斷進行維護。但Linode的創(chuàng)始人Chris Aker提出的一個驚人想法最終解決了這個問題。

方法的關(guān)鍵在于為所有CPU標記創(chuàng)建一個列表，并將其表示為一個二進制字符串。隨后，可以使用Bitwise and（“按位與”）運算來對比字符串。

對于實時遷移，CPU標記完整列表會表示為一個二進制字符串，其中每一位都代表一個標記。如果一個位為“0”，代表對應(yīng)的標記不存在；如果某個位為“1”，則代表標記存在。例如，一個位可以代表AES標記，另一個位可以代表MMX標記。這些標記在二進制字符串中的位置會維護并記錄在案，隨后用于我們數(shù)據(jù)中心內(nèi)的所有計算機。

相比維護一組if語句來檢查某個CPU標記是否存在，這種列表的維護工作無疑更簡單也更高效。例如，假設(shè)總共需要追蹤并檢查7個CPU標記，這些標記可以存儲在一個8位數(shù)字中（多出的一位供未來進行擴展）。例如這樣的字符串可能類似于00111011，最右側(cè)的一位代表AES已啟用，右數(shù)第二位代表MMX已啟用，右數(shù)第三位代表其他標記已啟用，以此類推。

實時遷移操作會在源和目標計算機上針對CPU標記字符串執(zhí)行“按位與”操作。如果兩個計算機的CPU標記字符串運算結(jié)果相等，意味著目標計算機是兼容的。我們的內(nèi)部工具可以使用上述算法得到的結(jié)果為可兼容的硬件構(gòu)建一個列表。該列表會展示給我們的客戶支持和硬件運維團隊，這些團隊可以使用我們的內(nèi)部工具來編排不同的運維任務(wù)。

緊跟技術(shù)變化的步伐

隨著時間推移，Linode會增加新的功能，我們也許要繼續(xù)努力保證實時遷移可以兼容這些功能。引入某些新功能時，可能無需圍繞實時遷移執(zhí)行新的開發(fā)工作，但我們可能依然需要測試該功能是否可以按照預(yù)期正常工作。對于某些功能，則可能需要在開發(fā)的早期階段，針對實時遷移進行必要的兼容性測試和相關(guān)工作。

和其他幾乎所有軟件類似，對于同一件事，通過不斷研究，總能發(fā)現(xiàn)更好的實現(xiàn)方法。例如，從長遠來看，為實時遷移功能開發(fā)更多模塊化的集成方法，無疑可以降低維護負擔?；蛘呶覀兩踔量赡軐崟r遷移的相關(guān)功能納入到底層代碼中，從而使其成為Linode一項拆箱即用的功能。

—————————————————————————————————————————————————

如您所在的企業(yè)也在考慮采購云服務(wù)或進行云遷移，

點擊鏈接了解Akamai Linode的解決方案