容器熱遷移的快速內(nèi)存同步技術(shù)

游強(qiáng)志,胡懷湘,陳相宇

(中國電子科技集團(tuán)第十五研究所,北京 100083)

0 引 言

云計(jì)算是一種融合了多項(xiàng)計(jì)算機(jī)技術(shù)的以集中式計(jì)算和存儲為特征的密集型計(jì)算模式[1],其中虛擬化技術(shù)是最為關(guān)鍵的技術(shù)之一。目前業(yè)界對虛擬化技術(shù)可以分為2類。一類是基于Hypervisor的容器化虛擬機(jī)技術(shù)[2]，其中以Hyper為代表。另一類是基于Namespace和Cgroups機(jī)制的容器技術(shù)[3]，其中以Docker為代表。

對于基于Hypervisor的容器化虛擬機(jī)熱遷移，其本質(zhì)上仍舊是基于傳統(tǒng)虛擬機(jī)的熱遷移技術(shù)。國內(nèi)外學(xué)者對于傳統(tǒng)虛擬機(jī)的熱遷移技術(shù)，進(jìn)行了廣泛而深入的研究。

虛擬機(jī)的遷移主要包括CPU狀態(tài)、內(nèi)存狀態(tài)、設(shè)備狀態(tài)[4]。日志重放和快照是虛擬機(jī)遷移中廣泛使用的2種方案[5]。其中基于日志重放機(jī)制的虛擬機(jī)遷移技術(shù)會記錄虛擬機(jī)的所有異步事件，然后在目的虛擬機(jī)上確定性地重放日志，以實(shí)現(xiàn)虛擬機(jī)端到端遷移的目的[6]。然而該種方法的弊端在于盡管在虛擬機(jī)監(jiān)視器的幫助下，日志記錄很容易完成，但是日志記錄的確定性重放很大程度上依賴于目標(biāo)體系結(jié)構(gòu)[7]。除此之外，對于多核CPU，跟蹤共享內(nèi)存是非常困難的。而快照機(jī)制的虛擬機(jī)遷移，待遷移虛擬機(jī)在運(yùn)行時(shí)其輸出將會被緩沖，與此同時(shí)虛擬機(jī)狀態(tài)會被打下快照，并且傳輸?shù)酱教摂M機(jī)上，當(dāng)主從虛擬機(jī)狀態(tài)同步完成后，輸出被刷新，遷移完成[8]。基于快照機(jī)制，設(shè)備狀態(tài)實(shí)質(zhì)上存儲在內(nèi)存中，而其余數(shù)據(jù)可以通過共享存儲[9]等方案快速傳輸，這就導(dǎo)致該種方案的主要開銷在于內(nèi)存同步。許多方案被提出以減小虛擬機(jī)遷移過程中內(nèi)存同步的開銷。其中應(yīng)用得最廣泛的一種技術(shù)是預(yù)拷貝(pre-copy)技術(shù)，通過多次迭代拷貝將源虛擬機(jī)的內(nèi)存拷貝至目標(biāo)主機(jī)，每次拷貝只傳輸源虛擬機(jī)中的臟內(nèi)存，能夠大大減少虛擬機(jī)的停機(jī)時(shí)間和傳輸損耗[10]。該種方法的弊端在于如果內(nèi)存修改過于頻繁，某些熱點(diǎn)內(nèi)存頁可能被反復(fù)傳輸，造成資源的浪費(fèi)，甚至導(dǎo)致迭代過程無法收斂[11]，造成遷移失敗的情況。為解決這個(gè)問題，很多基于預(yù)拷貝的改進(jìn)算法被提了出來。例如對每輪傳輸?shù)膬?nèi)存頁進(jìn)行統(tǒng)計(jì)，將傳輸頻繁的熱點(diǎn)內(nèi)存頁留到最后一輪傳輸[12]，以減少傳輸總量。還有通過CPU調(diào)度減少遷移過程中內(nèi)存臟頁的生成速率，保證遷移的順利進(jìn)行，但這樣不可避免會造成虛擬機(jī)性能的下降[13]。除此之外，包括利用局部性原理優(yōu)化內(nèi)存拷貝[14]、計(jì)算內(nèi)存臟頁率并分頻傳輸[15]、預(yù)測內(nèi)存修改頻率[16]、對內(nèi)存臟頁進(jìn)行分類并多路復(fù)用傳輸[17]等方案，目的都是減少內(nèi)存?zhèn)鬏斂偭?，從而保證遷移的順利進(jìn)行。與預(yù)拷貝技術(shù)對應(yīng)的，另一種遷移算法是后拷貝(post-copy)，該算法一次性將所有內(nèi)存頁拷貝到目的主機(jī)，隨即切換服務(wù)，僅當(dāng)目的主機(jī)上發(fā)生頁錯(cuò)誤時(shí)，才將源虛擬機(jī)中對應(yīng)的內(nèi)存頁復(fù)制過來，以保證每個(gè)內(nèi)存頁只被傳輸一次[18]。但后拷貝可能導(dǎo)致服務(wù)的不可用，以及停機(jī)時(shí)間過長等弊端[19]。因此，學(xué)術(shù)界提出了一種名為混合方案的新遷移算法，以綜合預(yù)拷貝和后拷貝2種算法的優(yōu)勢，即先進(jìn)行預(yù)拷貝，令源虛擬機(jī)在正常運(yùn)行的情況下將全部內(nèi)存頁復(fù)制到目的虛擬機(jī)，隨后啟動目的虛擬機(jī)提供服務(wù)，使用后拷貝對內(nèi)存臟頁進(jìn)行處理[20]。

目前為止預(yù)拷貝算法廣泛應(yīng)用于工業(yè)界當(dāng)中，而其余算法更多還僅是停留在學(xué)術(shù)界的討論當(dāng)中。

與基于Hypervisor的重量級虛擬化技術(shù)相比，以Docker為代表的虛擬化是一種基于操作系統(tǒng)層級的輕量級虛擬化技術(shù)，一個(gè)容器實(shí)質(zhì)上等同于一個(gè)進(jìn)程。

相較于傳統(tǒng)容器化虛擬機(jī)的遷移，學(xué)術(shù)界針對容器熱遷移的研究比較少。目前容器的熱遷移主要依賴的技術(shù)是CRIU技術(shù)，首先對容器進(jìn)行Checkpoint操作，將容器的CPU、內(nèi)存等信息存儲為文件，容器隨后停機(jī)，將信息文件拷貝到目的主機(jī)上，執(zhí)行Restore操作恢復(fù)容器繼續(xù)工作[21]。該種方案中，在傳輸過程及恢復(fù)過程中容器完全停機(jī)，通常導(dǎo)致停機(jī)時(shí)間較長。除此之外，也有人嘗試使用日志記錄容器運(yùn)行過程中的事件，隨后在目的端容器中進(jìn)行回放，回放完成后停止源容器[22]。該種方案依賴于計(jì)算機(jī)的系統(tǒng)結(jié)構(gòu)，并且在多CPU的應(yīng)用場景下，很難做到日志的確定性重放，所以該方案目前仍舊停留在理論研究中，不適用于云平臺、集群的應(yīng)用場景下。

本文主要針對以Docker為代表的容器虛擬化的熱遷移技術(shù)，基于預(yù)拷貝(pre-copy)算法設(shè)計(jì)并實(shí)現(xiàn)容器在不同主機(jī)之間的熱遷移方案，并提出3種改進(jìn)策略，以滿足容器熱遷移過程中減少停機(jī)時(shí)間及傳輸性能上的優(yōu)化。

1 容器熱遷移方案設(shè)計(jì)

1.1 設(shè)計(jì)目標(biāo)

本文中的容器熱遷移，針對的是用戶無感知情況下，容器跨節(jié)點(diǎn)間的遷移，遷移過程必須實(shí)現(xiàn)以下幾個(gè)目標(biāo)：

1)透明性。透明性是指在遷移過程中應(yīng)該對用戶保持透明化，即在容器遷移發(fā)生時(shí)，對外服務(wù)應(yīng)當(dāng)保持正常，在用戶無感知的情況下完成容器的遷移過程。

2)實(shí)時(shí)性。實(shí)時(shí)是指不停機(jī)的一種遷移方式，即在遷移過程中保證服務(wù)的高可用，但在單容器運(yùn)行情況下的遷移無法做到完全不停機(jī)，在本文中的容器遷移應(yīng)當(dāng)做到遷移過程中的停機(jī)時(shí)間盡可能地短。

3)一致性。一致性是指在遷移前后，容器的進(jìn)程運(yùn)行狀態(tài)應(yīng)當(dāng)與遷移前在源主機(jī)上的容器進(jìn)程狀態(tài)保持一致。

4)節(jié)能性。在實(shí)際生產(chǎn)場景中，容器鏡像跨節(jié)點(diǎn)的傳輸速度取決于帶寬，通常來說，一臺主機(jī)上會運(yùn)行多個(gè)容器，共享主機(jī)的帶寬資源，所以在滿足上述3個(gè)目標(biāo)的前提下，應(yīng)盡量減小傳輸消耗。

1.2 方案設(shè)計(jì)

容器傳統(tǒng)的遷移過程由4個(gè)階段組成：運(yùn)行階段、檢查點(diǎn)(checkpoint)階段、傳輸階段、和恢復(fù)(restore)階段。容器經(jīng)由檢查點(diǎn)階段將容器的狀態(tài)信息輸出為文件保存，隨后容器停止，經(jīng)過傳輸階段傳輸?shù)侥康闹鳈C(jī)上，通過恢復(fù)階段恢復(fù)運(yùn)行。

如圖1所示，在容器傳統(tǒng)遷移過程中，容器的停機(jī)時(shí)間包括傳輸階段和恢復(fù)階段。然而正常使用的容器產(chǎn)生的狀態(tài)信息文件大小可以達(dá)到GB級，在帶寬受限的情況下會導(dǎo)致停機(jī)時(shí)間過長，影響服務(wù)的正常使用，無法實(shí)現(xiàn)實(shí)時(shí)遷移的目的。

圖1 容器傳統(tǒng)遷移

為了減少停機(jī)時(shí)間，基于預(yù)拷貝(pre-copy)算法對容器傳統(tǒng)遷移算法進(jìn)行優(yōu)化。

如圖2所示，遷移流程可以總結(jié)為如下步驟：

圖2 基于pre-copy算法的容器遷移流程

1)生成容器的全量檢查點(diǎn)，并將生成的狀態(tài)文件傳輸?shù)侥繕?biāo)主機(jī)，保持容器運(yùn)行。

2)生成容器的增量檢查點(diǎn)，增量檢查點(diǎn)中主要包含2次檢查點(diǎn)之間的臟內(nèi)存信息。

3)判斷步驟2中產(chǎn)生的增量檢查點(diǎn)大小是否小于閾值，如果是，進(jìn)行步驟4，否則進(jìn)行步驟5。

4)判斷迭代傳輸輪次是否達(dá)到上限，是則進(jìn)行步驟5，否則傳輸該檢查點(diǎn)，重復(fù)步驟2。

5)停止容器，傳輸最后一次的檢查點(diǎn)。

6)在目的主機(jī)上恢復(fù)容器。

根據(jù)上述步驟，如圖3所示，該算法中容器的停機(jī)時(shí)間包括最后一次增量檢查點(diǎn)的傳輸時(shí)間和容器的恢復(fù)時(shí)間。增量檢查點(diǎn)的閾值通過人為設(shè)定為明顯小于全量檢查點(diǎn)的大小，能夠大大減少傳輸時(shí)間，從而達(dá)到減少停機(jī)時(shí)間的目的。

圖3 基于pre-copy算法的容器遷移階段

1.3 模塊設(shè)計(jì)

相較于傳統(tǒng)的基于CRIU技術(shù)實(shí)現(xiàn)的checkpoint/restore容器熱遷移，本文設(shè)計(jì)的基于預(yù)拷貝算法的容器遷移方案與之最大的區(qū)別在于內(nèi)存拷貝時(shí)，對臟內(nèi)存的處理以及2種檢查點(diǎn)的使用，在CRIU技術(shù)的基礎(chǔ)上設(shè)計(jì)遷移系統(tǒng)的模塊如下：

1)檢查點(diǎn)模塊。

2)傳輸模塊。

3)恢復(fù)模塊。

1.3.1 檢查點(diǎn)模塊

檢查點(diǎn)模塊負(fù)責(zé)將容器進(jìn)程的狀態(tài)信息全量或增量存儲為鏡像文件，該模塊的實(shí)現(xiàn)主要依賴于/proc文件系統(tǒng)，鏡像文件中主要包含以下內(nèi)容：

1)文件描述信息，通過/proc/＄pid/fd和/proc/＄pid/fdinfo進(jìn)行收集。

2)進(jìn)程參數(shù)信息，通過調(diào)用ptrace接口和解析/proc/＄pid/stat進(jìn)行收集。

3)內(nèi)存映射信息，通過/proc/＄pid/maps和/proc/＄pid/map_files/收集。

在開始檢查點(diǎn)進(jìn)程之前，必須保證檢查點(diǎn)進(jìn)程不會改變原先容器進(jìn)程的運(yùn)行狀態(tài)，并且為了保證檢查點(diǎn)的有效性，在進(jìn)行檢查點(diǎn)操作時(shí)，容器進(jìn)程及其子進(jìn)程狀態(tài)必須是不變的。一般而言，可以通過停止信號“殺死”進(jìn)程，但這樣就改變了容器進(jìn)程的運(yùn)行狀態(tài)，所以這里通過調(diào)用ptrace接口暫時(shí)地凍結(jié)進(jìn)程樹。

然后，為了收集進(jìn)程的內(nèi)存數(shù)據(jù)，通過調(diào)用ptrace接口向進(jìn)程注入寄生蟲代碼，每當(dāng)mmap進(jìn)行內(nèi)存文件映射時(shí)，檢查點(diǎn)模塊將寄生蟲代碼拷貝到相應(yīng)的進(jìn)程地址空間，收集內(nèi)存數(shù)據(jù)。在收集完所有信息后，由于寄生蟲代碼本身會占用內(nèi)存，為了盡可能減少對容器進(jìn)程的影響，需要對其進(jìn)行清除。

檢查點(diǎn)模塊的具體工作流程如下：

1)根據(jù)容器進(jìn)程的pid遞歸地遍歷/proc/＄pid/task/和/proc/＄pid/task/＄tid/children收集容器進(jìn)程及其子進(jìn)程構(gòu)成的進(jìn)程樹信息。調(diào)用ptrace接口的PTRACE_SEIZE命令凍結(jié)進(jìn)程樹。

2)檢查點(diǎn)模塊收集容器進(jìn)程中可獲取的資源信息，包括文件描述信息、進(jìn)程參數(shù)信息、內(nèi)存映射信息等，并寫入文件。

3)向容器進(jìn)程中動態(tài)注入PIE(Position-independent code)格式的寄生蟲代碼[23]。當(dāng)容器進(jìn)程調(diào)用mmap操作時(shí)，寄生蟲代碼被拷貝到對應(yīng)的地址空間，記錄隨后的內(nèi)存變化。

1.3.2 傳輸模塊

傳輸模塊通過使用Linux的SCP命令，負(fù)責(zé)將檢查點(diǎn)模塊生成的鏡像文件迭代地從源主機(jī)傳輸?shù)侥康闹鳈C(jī)。

1.3.3 恢復(fù)模塊

恢復(fù)模塊負(fù)責(zé)在目的主機(jī)上合并迭代傳輸過來的容器鏡像文件，并恢復(fù)容器運(yùn)行。其中鏡像文件分為2類，一類是第一次傳輸?shù)娜萜魅啃畔?，另一類為迭代預(yù)拷貝過程中生成的內(nèi)存臟頁信息，恢復(fù)模塊負(fù)責(zé)將內(nèi)存頁信息鏡像文件合并成一個(gè)文件，并以生成的鏡像文件信息恢復(fù)容器的運(yùn)行。

恢復(fù)模塊的工作流程：

1)合并傳輸收到的多個(gè)內(nèi)存頁鏡像文件，得到最終的內(nèi)存頁鏡像文件。

2)恢復(fù)模塊讀取合成的鏡像文件，并且解析鏡像文件中進(jìn)程的共享資源，隨后共享資源的恢復(fù)存在2種方式，一是由某個(gè)進(jìn)程恢復(fù)，其他進(jìn)程之后繼承，二是通過其他方式恢復(fù)，如通過memfd文件描述符恢復(fù)共享內(nèi)存。

3)恢復(fù)模塊遞歸地生成需要恢復(fù)的進(jìn)程樹，恢復(fù)進(jìn)程的基本資源，在這個(gè)階段，恢復(fù)模塊將會恢復(fù)容器進(jìn)程打開的文件、準(zhǔn)備命名空間、填充私有內(nèi)存數(shù)據(jù)、創(chuàng)建套接字等等。

從表5三次考查結(jié)果可以看出，進(jìn)入錫石浮選脫泥前-0.010 mm粒級產(chǎn)率為56.68%，含泥較高，經(jīng)過三次脫泥后，有45.30%的錫金屬進(jìn)入錫石浮選中，整個(gè)錫石浮選作業(yè)效率達(dá)到79.44%，對原礦的回收率為5.15%。超過了預(yù)期目標(biāo)。

4)對于步驟3中創(chuàng)建的進(jìn)程，注入寄生蟲代碼，執(zhí)行munmap和mmap操作取消舊內(nèi)存映射，并恢復(fù)成容器原本的內(nèi)存映射，恢復(fù)計(jì)時(shí)器、線程等。

5)調(diào)用ptrace接口清除步驟4中注入的寄生蟲代碼，恢復(fù)進(jìn)程運(yùn)行。

2 快速內(nèi)存同步優(yōu)化設(shè)計(jì)

2.1 細(xì)粒度臟內(nèi)存識別

在基于CRIU進(jìn)行臟內(nèi)存跟蹤時(shí)，實(shí)質(zhì)上是通過虛擬內(nèi)存寫保護(hù)機(jī)制來實(shí)現(xiàn)的。每次修改內(nèi)存頁時(shí)，都會出現(xiàn)寫保護(hù)，這將導(dǎo)致嘗試寫入進(jìn)程內(nèi)存頁面時(shí)發(fā)生頁面錯(cuò)誤，與此同時(shí)記錄下本次寫入的內(nèi)存頁，隨后繼續(xù)完成操作。

雖然虛擬內(nèi)存寫保護(hù)機(jī)制十分方便，但是當(dāng)內(nèi)存修改頻繁時(shí)，這種機(jī)制可能帶來不小的性能開銷。除此之外，這種機(jī)制對臟內(nèi)存的追蹤粒度級別是內(nèi)存頁，這意味著哪怕某個(gè)存儲頁中只有單個(gè)字節(jié)被修改，整個(gè)內(nèi)存頁也被認(rèn)為是臟內(nèi)存頁，可能造成額外的傳輸開銷。

為了解決上述問題，本文引入一種細(xì)粒度的臟內(nèi)存識別技術(shù)。與跟蹤整個(gè)頁不同，可以將一個(gè)內(nèi)存頁細(xì)分為若干個(gè)塊，并且為每個(gè)塊計(jì)算一個(gè)哈希值，并將這些哈希值存儲在內(nèi)存中。在檢查點(diǎn)階段，為每個(gè)塊計(jì)算一次當(dāng)前的哈希值，如果與上一次檢查點(diǎn)階段的哈希值不同，替換為新的哈希值，將相應(yīng)的塊標(biāo)記為臟塊，最后傳輸階段，只傳輸臟內(nèi)存塊，而不是整個(gè)頁。

內(nèi)存塊的大小越小，識別的臟內(nèi)存也越準(zhǔn)確，但也會帶來更大的內(nèi)存開銷。對于一個(gè)典型的內(nèi)存頁(4 kB)，假定一個(gè)塊的大小為256 B，每個(gè)哈希值占用8 B，額外的內(nèi)存開銷約為3.1%，而當(dāng)塊的大小為128 B時(shí)，額外的內(nèi)存開銷約為6.3%。除此之外，計(jì)算哈希值也會增加額外的開銷，但在本文的測試機(jī)上，MD5哈希計(jì)算的吞吐量約為320 MB/s，遠(yuǎn)高于專用千兆以太網(wǎng)鏈路的持續(xù)吞吐量128 MB/s，內(nèi)存塊的哈希值計(jì)算可以很容易地與傳輸過程一起流水化。

2.2 臟內(nèi)存壓縮傳輸

基于預(yù)拷貝算法的容器熱遷移過程中需要迭代地拷貝若干次臟內(nèi)存，勢必會占用一部分的帶寬資源。而在云環(huán)境的應(yīng)用場景下，同一主機(jī)上的帶寬是有限的，為了減少迭代傳輸所占用的帶寬，本文對臟內(nèi)存進(jìn)行壓縮傳輸。

幾種常見的壓縮算法對比如表1所示。

表1 常見壓縮算法對比

壓縮和解壓過程會增加內(nèi)存開銷，并且需要時(shí)間。為了保證在迭代過程中壓縮、傳輸、解壓、恢復(fù)過程能夠流水化，要求壓縮算法的壓縮速度至少要高于專用千兆以太網(wǎng)鏈路的最大吞吐量128 MB/s，本文使用Zippy/Snappy壓縮算法。

Zippy/Snappy是一種基于最近鄰算法(K-Nearest Neighbours)，旨在實(shí)現(xiàn)高速與合理壓縮比的一個(gè)壓縮、解壓庫[24]。

假設(shè)最后一次檢查點(diǎn)大小為x，壓縮速率是v1，壓縮率為y，解壓速率是v2，網(wǎng)絡(luò)傳輸速率是v3，可以得到最后一次傳輸過程時(shí)間，引入壓縮/解壓縮時(shí)間與不引入的比值為v3(v2+yv1)/v1v2，在實(shí)驗(yàn)室中該值僅為5%，對停機(jī)時(shí)間影響不大。

2.3 提前合并內(nèi)存鏡像

在恢復(fù)容器運(yùn)行之前，恢復(fù)模塊需要將目的主機(jī)上接收的內(nèi)存鏡像文件合并，并基于生成的最終內(nèi)存鏡像文件恢復(fù)新的容器進(jìn)程。也就是說，事實(shí)上，最終只需要最后生成的合并鏡像文件，而合并過程可以與鏡像傳輸過程一起進(jìn)行，即進(jìn)行預(yù)合并操作。

容器生成的內(nèi)存鏡像文件有2類，一類是pagemap.img，該文件中存儲內(nèi)存的映射關(guān)系，例如圖4中pagesmap1.img，表示前4個(gè)內(nèi)存頁將從pages.img中讀取并放置到地址0x1000000處。當(dāng)執(zhí)行增量檢查點(diǎn)時(shí)，pagemap.img中會增加一個(gè)標(biāo)示位in_parent，表示這些內(nèi)存頁從前一個(gè)檢查點(diǎn)讀取。另一類文件為pages.img，存儲內(nèi)存頁的具體內(nèi)容。

預(yù)合并過程實(shí)現(xiàn)如圖4所示。

圖4 預(yù)合并過程

假設(shè)目的主機(jī)上接收到了N批內(nèi)存鏡像文件，其中包括一份全量狀態(tài)鏡像文件和N-1份臟內(nèi)存鏡像文件，需要執(zhí)行N-1次合并操作。若進(jìn)行預(yù)合并操作，理想情況下只需要執(zhí)行最后一份臟內(nèi)存鏡像文件和容器鏡像文件即可，即執(zhí)行1次合并操作，能夠有效減少恢復(fù)階段造成的停機(jī)時(shí)間。

在實(shí)驗(yàn)機(jī)上測量，預(yù)合并的速度約為135 MB/s，高于專用千兆以太網(wǎng)鏈路的持續(xù)吞吐量128 MB/s，可以與傳輸過程一起流水化進(jìn)行。

3 實(shí)驗(yàn)與比較

本章中的實(shí)驗(yàn)環(huán)境是2臺完全一樣的物理機(jī)，物理機(jī)硬件配置如表2所示，軟件配置如表3所示。2臺物理機(jī)與1臺路由器構(gòu)成簡單的網(wǎng)絡(luò)拓?fù)洹?/p>

表2 主機(jī)硬件配置

表3 主機(jī)軟件配置

為了方便對比不同內(nèi)存更新率的情況下的實(shí)驗(yàn)結(jié)果，本文使用Linux容器，通過Linux性能壓測工具Stress來模擬容器在不同負(fù)載下的情況，默認(rèn)Stress使用1個(gè)進(jìn)程，不停申請并釋放內(nèi)存，間隔時(shí)間為1024 ms。容器的相關(guān)配置如表4所示。

表4 容器配置

3.1 細(xì)粒度臟內(nèi)存識別

在容器中，使用Stress軟件分別申請512 MB、1024 MB、2048 MB內(nèi)存，不停地計(jì)算隨機(jī)數(shù)的平方根并寫入內(nèi)存，設(shè)置檢查點(diǎn)迭代間隔大小為500 ms，迭代閾值設(shè)置為全量檢查點(diǎn)大小的50%，迭代上限設(shè)置為10次時(shí)，容器遷移過程中的傳輸字節(jié)總量與內(nèi)存分塊大小的關(guān)系如圖5所示。

圖5 傳輸字節(jié)量與塊大小關(guān)系

隨著內(nèi)存塊大小的增加，整個(gè)遷移過程中傳輸?shù)淖止?jié)總量會增大。對比3條曲線可以看出，寫內(nèi)存越稀疏，傳輸總量也會增大。

3.2 臟內(nèi)存壓縮傳輸

在容器中，使用Stress軟件申請1024 MB內(nèi)存，不停地計(jì)算隨機(jī)數(shù)的平方根并寫入內(nèi)存，迭代閾值設(shè)置為全量檢查點(diǎn)大小的50%，迭代上限設(shè)置為10次時(shí)，使用Zippy/Snappy壓縮和不使用壓縮時(shí)，傳輸總量的大小與迭代間隔大小的關(guān)系如圖6所示。

圖6 傳輸字節(jié)量與迭代間隔大小的關(guān)系

實(shí)際上，由于壓縮對象主要是內(nèi)存信息，格式都是二進(jìn)制文件，Snappy能夠?qū)崿F(xiàn)的壓縮比遠(yuǎn)高于0.22這個(gè)比率，對比不進(jìn)行壓縮的情況下，傳輸開銷明顯減少。

3.3 提前合并內(nèi)存鏡像

使用Stress軟件，申請1 GB內(nèi)存、閾值設(shè)置為全量檢查點(diǎn)大小的50%時(shí)，采用pre-restore提前合并內(nèi)存鏡像與正常restore恢復(fù)過程所需要花費(fèi)的時(shí)間與迭代間隔的大小如圖7所示，恢復(fù)時(shí)間與迭代輪次的關(guān)系如圖8所示。

圖7 恢復(fù)時(shí)間與迭代間隔大小關(guān)系

圖8 恢復(fù)時(shí)間與迭代輪次關(guān)系

隨著迭代輪次的增大，未使用預(yù)合并內(nèi)存鏡像所需要的恢復(fù)時(shí)間明顯增加，而使用了預(yù)合并內(nèi)存鏡像所需要的恢復(fù)時(shí)間基本保持不變。事實(shí)上迭代輪次的大小通常與迭代閾值的大小成正相關(guān)關(guān)系，預(yù)合并內(nèi)存鏡像能夠明顯減少恢復(fù)時(shí)間。

3.4 總結(jié)

當(dāng)?shù)撝翟O(shè)置為全量檢查點(diǎn)大小的50%，迭代間隔為500 ms，在容器中使用Stress軟件申請512 MB內(nèi)存，迭代輪次上限設(shè)置為10次，不停地計(jì)算隨機(jī)數(shù)的平方根并寫入內(nèi)存。對該容器進(jìn)行熱遷移的實(shí)驗(yàn)結(jié)果如表5所示。

表5 512 MB實(shí)驗(yàn)結(jié)果

從表5可以看到，與傳統(tǒng)checkpoint/restore機(jī)制的遷移方式比，采用預(yù)拷貝(pre-copy)方式產(chǎn)生的停機(jī)時(shí)間并沒有明顯優(yōu)化，這是由于迭代輪次增加，恢復(fù)時(shí)間增加所導(dǎo)致的。當(dāng)采用細(xì)粒度臟內(nèi)存跟蹤優(yōu)化后，停機(jī)時(shí)間僅為傳統(tǒng)遷移方式的77%，傳輸總量為預(yù)拷貝方式的45%。當(dāng)采用預(yù)合并鏡像后，停機(jī)時(shí)間減少了61%。當(dāng)采用壓縮臟內(nèi)存?zhèn)鬏攦?yōu)化后，傳輸總量比傳統(tǒng)遷移方式減少了近一半。最后，進(jìn)行了優(yōu)化后的預(yù)拷貝容器熱遷移機(jī)制，相比于傳統(tǒng)的checkpoint/restore遷移機(jī)制，停機(jī)時(shí)間減少了77%，傳輸總量減少了63%，停機(jī)時(shí)間和傳輸節(jié)能獲得了明顯的優(yōu)化。

4 結(jié)束語

為了優(yōu)化容器熱遷移過程中產(chǎn)生的停機(jī)時(shí)間和傳輸開銷，本文設(shè)計(jì)并實(shí)現(xiàn)了一種基于預(yù)拷貝(pre-copy)算法的容器熱遷移方案，并且提出了3種優(yōu)化策略。實(shí)驗(yàn)表明，上述方案相比于傳統(tǒng)的checkpoint/restore遷移機(jī)制，停機(jī)時(shí)間減少了77%，傳輸開銷減少了63%，得到了明顯的優(yōu)化。