遠(yuǎn)程直接內(nèi)存訪問與檢查點相結(jié)合的容器遷移*

趙 倩，謝上欽，韓 軻，龔青澤，馮光升，林俊宇

1.哈爾濱商業(yè)大學(xué) 計算機(jī)與信息工程學(xué)院，哈爾濱 150028

2.哈爾濱工程大學(xué) 計算機(jī)科學(xué)與技術(shù)學(xué)院，哈爾濱 150001

3.中國科學(xué)院 信息工程研究所，北京 100093

1 引言

隨著云計算服務(wù)的普及，越來越多的任務(wù)和服務(wù)被部署到云計算集群上，利用虛擬化技術(shù)在硬件資源利用率、隔離性等方面的優(yōu)勢為用戶提供服務(wù)[1]。目前，云計算廠商大都采用完全虛擬化技術(shù)[2]、準(zhǔn)虛擬化技術(shù)[3]或操作系統(tǒng)虛擬化技術(shù)[4-5]給服務(wù)提供隔離的環(huán)境，增加了云計算集群的復(fù)雜性，導(dǎo)致集群容錯能力難以得到保障。傳統(tǒng)情況下，單一結(jié)構(gòu)的集群容錯方式難以適應(yīng)復(fù)雜的云計算異構(gòu)環(huán)境，一旦集群中某一結(jié)點出現(xiàn)故障，需要將該結(jié)點的任務(wù)和服務(wù)遷移到其他結(jié)點上繼續(xù)運行，難以滿足任務(wù)恢復(fù)的時效性和容錯性需求。

Linux容器技術(shù)（Linux container，LXC）是容器虛擬化技術(shù)的典型代表[6]，可以在單個宿主機(jī)操作系統(tǒng)上同時運行多個Linux 系統(tǒng)，使用控制組（control groups，CGROUPS）技術(shù)實現(xiàn)處理器、硬盤、內(nèi)存、I/O、網(wǎng)絡(luò)等設(shè)備的隔離。LXC提供了一個擁有自身進(jìn)程和網(wǎng)絡(luò)空間的虛擬環(huán)境，可以在單一結(jié)點上實現(xiàn)多個容器同時運行并保證良好隔離。相比傳統(tǒng)虛擬機(jī)，LXC只是容器級的虛擬化技術(shù)，是一種輕量級技術(shù)，啟動加載速度快，能夠平衡虛擬化程度和對資源消耗。LXC 目前還不支持容器的動態(tài)遷移機(jī)制，考慮到LXC 是由若干個進(jìn)程組來實現(xiàn)，因此LXC 容器的熱遷移可以借助進(jìn)程遷移機(jī)制來實現(xiàn)。典型的進(jìn)程遷移方案可通過檢查點和重啟來實現(xiàn)[7]，如CRIU（checkpoint/restore in userspace）[8]、Btrfs[9]等。Docker[10]作為LXC 管理工具的代表，其容錯機(jī)制則是基于檢查點和重啟實現(xiàn)的。

目前主流的容錯技術(shù)都是針對虛擬機(jī)和進(jìn)程，隨著容器虛擬化的推廣，研究容器容錯機(jī)制具有非常重要的意義。針對面向用戶級容錯的容器遷移機(jī)制展開探索，結(jié)合容器容錯資源分配過程，在前期工作的基礎(chǔ)上[11]，提出一種基于容器容錯池的容錯遷移機(jī)制，利用檢查點機(jī)制和遠(yuǎn)程直接內(nèi)存訪問（remote direct memory access，RDMA）技術(shù)，在不影響容器虛擬集群正常工作的前提下，為容器虛擬集群容錯提供支撐。

2 基于容器容錯池的容器遷移機(jī)制

隨著云計算集群中任務(wù)種類的增多，當(dāng)需要將任務(wù)遷移至容錯備機(jī)時，提供遷移環(huán)境的開銷增大，管理難度增大。為了提高容錯備機(jī)的利用效率同時降低容錯遷移拒絕率和容錯遷移延遲，提出一種基于容器容錯池的容器遷移機(jī)制，減少任務(wù)恢復(fù)環(huán)境耦合問題對任務(wù)遷移造成的影響。

2.1 容器遷移框架和容器容錯池框架

2.1.1 容器遷移原理

云計算平臺中分布著大量不同種類任務(wù)，任務(wù)負(fù)載具有高度的時變性特征，利用容器遷移技術(shù)進(jìn)行負(fù)載均衡和提高資源利用率具有可行性；當(dāng)集群中某一結(jié)點出現(xiàn)故障時，也可用容器遷移技術(shù)將服務(wù)轉(zhuǎn)移到可靠結(jié)點運行且不停機(jī)，從而為用戶提供無感知的服務(wù)遷移，滿足服務(wù)體驗要求。容器熱遷移是在不中斷客戶端服務(wù)或者用戶服務(wù)的情況下，在不同主機(jī)或云之間遷移服務(wù)程序的過程。在遷移過程中，容器的內(nèi)存、文件系統(tǒng)和網(wǎng)絡(luò)連接從源主機(jī)轉(zhuǎn)移到目的主機(jī)，并且一直保持在不停機(jī)狀態(tài)。容器熱遷移的基本原理可劃分為四個過程（如圖1所示）[12]：（1）凍結(jié)源結(jié)點上的容器，獲取容器的內(nèi)存、進(jìn)程、文件系統(tǒng)和網(wǎng)絡(luò)連接等狀態(tài)；（2）將這些狀態(tài)復(fù)制到目標(biāo)結(jié)點；（3）目標(biāo)結(jié)點恢復(fù)狀態(tài)并在此結(jié)點解凍容器；（4）源結(jié)點進(jìn)行快速清理。

值得注意的是，傳統(tǒng)的虛擬機(jī)熱遷移是通過定期將內(nèi)存頁從源主機(jī)復(fù)制到目的主機(jī)來實現(xiàn)，數(shù)據(jù)中心的管理平臺根據(jù)源主機(jī)和目的主機(jī)資源可用性來制定策略以及觸發(fā)遷移；與傳統(tǒng)的虛擬機(jī)熱遷移不同，容器遷移需要進(jìn)程遷移技術(shù)，與進(jìn)程相關(guān)聯(lián)的操作系統(tǒng)狀態(tài)（進(jìn)程控制塊、文件表、套接字等）須與內(nèi)存頁一起捕獲和保存，由于容器的內(nèi)存占用量小于傳統(tǒng)虛擬機(jī)，可減少遷移時間[13-15]。

Fig.1 Principle of container migration圖1 容器遷移原理

2.1.2 容器遷移框架邏輯結(jié)構(gòu)

基于容器虛擬化技術(shù)和容器遷移技術(shù)將傳統(tǒng)的容錯備機(jī)虛擬成容器容錯池，可以虛擬出大量的遷移環(huán)境，從而滿足云計算集群異構(gòu)環(huán)境下遷移任務(wù)對恢復(fù)環(huán)境高一致性的要求。為提高容錯資源利用率，并減少任務(wù)恢復(fù)環(huán)境耦合問題對任務(wù)遷移造成的影響，該小節(jié)提出一種具有容錯能力和可恢復(fù)集群中失效結(jié)點上任務(wù)的容器遷移框架，所提出的容器遷移框架如圖2所示。

管理結(jié)點負(fù)責(zé)任務(wù)遷移全局調(diào)度和容器容錯池的管理。管理結(jié)點的全局隊列負(fù)責(zé)接收云計算集群中的任務(wù)遷移請求，遷移管理模塊負(fù)責(zé)協(xié)調(diào)任務(wù)遷移，容錯池管理模塊負(fù)責(zé)管理容錯池中各類型容錯備機(jī)的類型轉(zhuǎn)換。服務(wù)結(jié)點是云計算集群中提供服務(wù)的主機(jī)，服務(wù)以容器的方式運行在服務(wù)結(jié)點上。容錯備機(jī)是容錯池中的物理主機(jī)，作為任務(wù)恢復(fù)的目的結(jié)點，云計算集群中的任務(wù)遷移最終遷移到容錯備機(jī)中。容錯池是集中管理的容錯備機(jī)資源，按提供任務(wù)恢復(fù)環(huán)境類型劃分為Hot、Warm、Cold 三種類型。每個容錯備機(jī)上運行著容器資源管理模塊，負(fù)責(zé)本機(jī)的容器管理和任務(wù)恢復(fù)工作。存儲系統(tǒng)用于存放檢查點文件。容錯備機(jī)和服務(wù)結(jié)點上都運行檢查點重啟代理（checkpoint-restart agent，CRA），CRA負(fù)責(zé)給容器和任務(wù)設(shè)置或恢復(fù)檢查點文件。每個結(jié)點上的協(xié)調(diào)模塊負(fù)責(zé)協(xié)調(diào)容器遷移過程。存儲系統(tǒng)上的I/O Server是檢查點文件系統(tǒng)與外界的傳輸接口，檢查點文件系統(tǒng)用于存儲任務(wù)的檢查點文件。

Fig.2 Framework of container migration圖2 容器遷移框架

容器遷移過程主要涉及到容器遷移的全局協(xié)調(diào)和容器容錯池的管理。對于多進(jìn)程的任務(wù)，全局協(xié)調(diào)有利于提高任務(wù)遷移的成功率。同時，通過全局協(xié)調(diào)優(yōu)化任務(wù)遷移請求在各個環(huán)境的等待時間，可以減少任務(wù)遷移恢復(fù)的延遲。容器容錯池的管理是為了提高容錯資源的利用率，縮短遷移環(huán)境管理對任務(wù)遷移的影響，減少任務(wù)遷移失效率，減少配置任務(wù)遷移環(huán)境產(chǎn)生的延遲。

2.1.3 容器容錯池框架及自動伸縮策略

根據(jù)容錯主機(jī)與遷移服務(wù)所需環(huán)境的吻合程度，將容器容錯池分為Hot、Warm、Cold三種類型，容錯資源的集中管理可以更好地分配容錯資源，及時拓展或收縮容錯池中的資源，降低能耗。容器遷移過程中，在容錯備機(jī)中恢復(fù)任務(wù)不僅需要容器和容器中任務(wù)的檢查點，還需在容錯備機(jī)中有相應(yīng)的容器鏡像。將有容器環(huán)境且處于關(guān)機(jī)狀態(tài)的容錯備機(jī)放入Cold 池，將有容器環(huán)境并處于待機(jī)狀態(tài)的容錯備機(jī)歸入Warm池，將有容器環(huán)境和容器鏡像并處于運行狀態(tài)的容錯備機(jī)歸為Hot 池。容器容錯池框架如圖3所示。

其中，容錯資源管理器負(fù)責(zé)容錯備機(jī)的管理，管理器由Hot、Warm、Cold 代理組成，分別負(fù)責(zé)Hot、Warm、Cold 類型主機(jī)的資源配置和容錯備機(jī)類型的轉(zhuǎn)換，如Cold 代理開啟Cold 主機(jī)并加載容器鏡像使其變?yōu)镠ot 主機(jī)。當(dāng)容器容錯池中有容器容錯資源請求到來時，容錯資源管理器首先將請求發(fā)送給Hot代理，如果Hot 池中有合適的備機(jī)，即具有容器鏡像的備機(jī)且備機(jī)資源足夠恢復(fù)任務(wù)，則Hot代理直接控制該備機(jī)恢復(fù)相應(yīng)的任務(wù)遷移請求。如果Hot 類型池中的備機(jī)不具備相應(yīng)的資源來恢復(fù)任務(wù)，則Hot代理將請求轉(zhuǎn)發(fā)給Warm代理，Warm代理在Warm類型池中尋找備機(jī)，并通過鏡像文件系統(tǒng)中獲取相應(yīng)的容器鏡像，將Warm類型備機(jī)轉(zhuǎn)變?yōu)镠ot類型備機(jī)，并在該備機(jī)中恢復(fù)任務(wù)之后將該備機(jī)交由Hot 代理管理。如果Warm 池中沒有備機(jī)可用，則Warm 代理將請求轉(zhuǎn)發(fā)給Cold 代理，Cold 代理從Cold 池中選取處于關(guān)機(jī)狀態(tài)的主機(jī)并激活后，從鏡像文件系統(tǒng)中獲取相應(yīng)的容器鏡像，將Cold類型備機(jī)轉(zhuǎn)變?yōu)镠ot類型備機(jī)，在該備機(jī)中恢復(fù)任務(wù)之后，將該備機(jī)交由Hot代理管理。

Fig.3 Framework of fault-tolerant pool圖3 容器容錯池框架

容錯池中，每臺運行恢復(fù)任務(wù)的主機(jī)要保持主機(jī)內(nèi)存負(fù)載在70%以下，帶寬負(fù)載在30%以下。Hot池中至少保持一臺主機(jī)內(nèi)存負(fù)載在70%以下，帶寬負(fù)載在30%以下。Warm 池根據(jù)設(shè)置維持臺主機(jī)，剩余容錯主機(jī)處于關(guān)機(jī)狀態(tài)，被Cold池管理。當(dāng)有Hot型主機(jī)上所有服務(wù)都運行完畢后，Hot代理將關(guān)閉該主機(jī)，并交由Cold 代理管理。Warm 代理負(fù)責(zé)Warm 類型備機(jī)的管理，Warm 型備機(jī)主要處于待機(jī)狀態(tài)，根據(jù)能耗需求可以調(diào)整Warm 型備機(jī)數(shù)量。Cold 代理負(fù)責(zé)管理Cold 型備機(jī)，Cold 備機(jī)可以被釋放為計算主機(jī)，不作為容錯資源，從而節(jié)約資源，也可以被激活并下載相應(yīng)容器鏡像，成為Hot類型備機(jī)。

2.2 檢查點和回卷機(jī)制

2.2.1 容器檢查點重啟方法

在Linux操作系統(tǒng)中的命名空間（如圖4中的父/子Namespaces）機(jī)制給進(jìn)程層級提供了隔離性和自包含性的資源隔離方案。

Fig.4 Theory of PID-Namespaces圖4 進(jìn)程編號-命名空間原理

由圖4可以看出容器及容器中任務(wù)在物理主機(jī)上經(jīng)過Namespaces 機(jī)制劃分的結(jié)果，容器內(nèi)部1號進(jìn)程為容器中所有進(jìn)程的父進(jìn)程，容器內(nèi)1號進(jìn)程和容器內(nèi)其他進(jìn)程在宿主機(jī)中都與相應(yīng)的進(jìn)程編號一一映射，容器內(nèi)所有進(jìn)程組成了任務(wù)進(jìn)程層級。通過檢查點操作可以給容器及其內(nèi)部的任務(wù)設(shè)置檢查點，通過重啟操作可以恢復(fù)容器和容器內(nèi)部的任務(wù)。

檢查點操作設(shè)置檢查點需要以下步驟：

（1）凍結(jié)遷移任務(wù)進(jìn)程層級下所有進(jìn)程，確保檢查點的全局一致性；

（2）記錄全局?jǐn)?shù)據(jù)，包括配置信息和容器的全局狀態(tài)；

（3）記錄遷移任務(wù)的進(jìn)程層級關(guān)系；

（4）記錄單個進(jìn)程的狀態(tài)，包括資源描述符、阻塞和掛起信號、CPU 寄存器數(shù)據(jù)、打開的文件、虛擬內(nèi)存等；

（5）解凍任務(wù)層級下的所有進(jìn)程使任務(wù)繼續(xù)運行，或者終止所有進(jìn)程以便進(jìn)行任務(wù)遷移工作。

檢查點設(shè)置由CRA 完成，從用戶的角度不需要更改用戶任務(wù)的代碼，不需要用戶任務(wù)與CRA 建立聯(lián)系，CRA對于用戶任務(wù)是透明的。以Linux系統(tǒng)為例，CRA需要存儲以下文件信息：

（1）存儲Linux 系統(tǒng)/proc/pid/smaps 文件和/proc/pid/map_files/目錄連接用來確定遷移任務(wù)使用的內(nèi)存空間，遷移任務(wù)映射的文件，遷移任務(wù)分割MAP_SHARED區(qū)域的共享內(nèi)存標(biāo)識符；

（2）/proc/pid/pagemap文件中重要的標(biāo)識符；

（3）當(dāng)前顯示的物理頁面，匿名MAP_FILE |MAP_PRIVATE映射。

恢復(fù)檢查點過程如下：

（1）創(chuàng)建一個新的容器環(huán)境并配置成遷移任務(wù)的運行環(huán)境；

（2）根據(jù)檢查點文件創(chuàng)建遷移任務(wù)的進(jìn)程層級；

（3）根據(jù)檢查點文件的設(shè)置順序恢復(fù)所有進(jìn)程的狀態(tài)；

（4）運行所遷移任務(wù)進(jìn)程層級下的所有進(jìn)程繼續(xù)運行。

任務(wù)恢復(fù)過程由容錯備機(jī)的容器資源管理模塊協(xié)助，容器資源管理模塊負(fù)責(zé)創(chuàng)建和配置容器運行所需的環(huán)境，并在容器中生成遷移任務(wù)的進(jìn)程層級。一旦進(jìn)程層級完成所有的進(jìn)程將執(zhí)行系統(tǒng)調(diào)用重啟函數(shù)恢復(fù)運行。保證容器恢復(fù)后容器內(nèi)任務(wù)的完整性，生成的進(jìn)程層級結(jié)構(gòu)需要保持進(jìn)程之間的依賴關(guān)系，例如父子進(jìn)程關(guān)系、線程、進(jìn)程組和會話等。因為進(jìn)程層級是在用戶空間生成的，進(jìn)程之間的依賴關(guān)系必須在恢復(fù)過程中建立，因此任務(wù)恢復(fù)過程必須依據(jù)檢查點文件中存儲的進(jìn)程層級關(guān)系。進(jìn)程恢復(fù)的過程是非常重要的，而且一些依賴關(guān)系沒有直接在進(jìn)程層級結(jié)構(gòu)中反映，如孤兒進(jìn)程必須在正確的會話組中恢復(fù)。

一旦進(jìn)程層級被恢復(fù)，所有的進(jìn)程通過重啟系統(tǒng)，根據(jù)檢查點順序在內(nèi)核中恢復(fù)。在CRA 的協(xié)助下，遷移任務(wù)進(jìn)程層級下的子進(jìn)程依次恢復(fù)。內(nèi)核中，重啟函數(shù)被外部調(diào)用觸發(fā)。首先，CRA創(chuàng)建通用恢復(fù)數(shù)據(jù)結(jié)構(gòu)，所有進(jìn)程將狀態(tài)寫入各自的恢復(fù)數(shù)據(jù)結(jié)構(gòu)以達(dá)到完全的恢復(fù)初始化狀態(tài)。然后，CRA讓第一個進(jìn)程開始恢復(fù)，并等待所有進(jìn)程都被恢復(fù)。最后，CRA通知任務(wù)恢復(fù)正常運行，并從系統(tǒng)調(diào)用中返回。

相應(yīng)的，待恢復(fù)的進(jìn)程等待CRA 通知恢復(fù)數(shù)據(jù)結(jié)構(gòu)已經(jīng)準(zhǔn)備完畢，然后待恢復(fù)進(jìn)程開始初始化它們的狀態(tài)。然后各個進(jìn)程按照進(jìn)程恢復(fù)層級的順序依次運行，從檢查點文件中獲取狀態(tài)，并通知下一個進(jìn)程開始恢復(fù)，并等待CRA的正常運行通知。當(dāng)所有進(jìn)程成功地恢復(fù)相應(yīng)狀態(tài)后，遷移任務(wù)可以成功運行。

2.2.2 容器遷移回卷機(jī)制

云計算中心中可以運行各種各樣的服務(wù)。針對科學(xué)計算程序，如消息傳遞接口（message passing interface，MPI）程序，對服務(wù)的持續(xù)性要求較高，周期性設(shè)置檢查點就可以滿足保存服務(wù)狀態(tài)，減少系統(tǒng)崩潰對服務(wù)造成的損失。對于Web 服務(wù)等實時服務(wù)，一旦服務(wù)回卷，將會降低用戶體驗。同時，Web服務(wù)通常通過cookie 和session 機(jī)制保存用戶狀態(tài)，并結(jié)合服務(wù)集群的方式進(jìn)行服務(wù)容錯。每個Web請求只有幾秒中的時間，不適用檢查點文件來保存服務(wù)器程序的狀態(tài)?？梢钥闯?，回卷機(jī)制主要針對耗時較長的計算程序，對這類程序可進(jìn)行有效的檢查點設(shè)置。

如圖5所示，服務(wù)程序在T1時刻的服務(wù)狀態(tài)是t1，此時通過C/R管理器對任務(wù)設(shè)置檢查點保存t1狀態(tài)。設(shè)置檢查點后系統(tǒng)得到保存服務(wù)狀態(tài)t1的檢查點文件。完成檢查點設(shè)置后時刻為T2，服務(wù)繼續(xù)運行。在T3時刻，服務(wù)的狀態(tài)為t3。此時由于系統(tǒng)故障或者其他因素需要將服務(wù)從源主機(jī)遷移到容錯主機(jī)上，C/R 管理器通過T1時刻設(shè)置的檢查點文件t1在容錯主機(jī)上恢復(fù)了服務(wù)，此時服務(wù)的狀態(tài)是t1，源主機(jī)上的服務(wù)被主動或被迫終止。此時服務(wù)的狀態(tài)為t1，服務(wù)發(fā)生回卷，回卷過程中服務(wù)丟失了T3時刻到T2時刻之間的狀態(tài)。如果服務(wù)只由一個進(jìn)程組成，這種回卷對服務(wù)結(jié)果沒有影響，如果服務(wù)與其他服務(wù)協(xié)同工作，回卷很可能給前序服務(wù)程序造成數(shù)據(jù)污染。因此在給服務(wù)設(shè)置檢查點的時候，需要考慮服務(wù)程序在云環(huán)境中的關(guān)聯(lián)性。

服務(wù)回卷對服務(wù)組的影響可根據(jù)其他服務(wù)對回卷服務(wù)產(chǎn)生數(shù)據(jù)的依賴程度采用不同的應(yīng)對策略。采用劃分服務(wù)組協(xié)同回卷機(jī)制，管理結(jié)點上的遷移管理模塊會將有關(guān)聯(lián)的服務(wù)列入一個同步表中，當(dāng)給處在某一關(guān)聯(lián)中的一個服務(wù)設(shè)置檢查點時，遷移管理模塊向同步表中所有服務(wù)發(fā)送控制信息，同步檢查點的設(shè)置。當(dāng)恢復(fù)服務(wù)時，同步表中的服務(wù)同時恢復(fù)。

2.3 容器遷移流程

容器遷移可以通過用戶請求或故障預(yù)測機(jī)制觸發(fā)。圖6描繪了基于容器的任務(wù)遷移——容器遷移期間不同組件之間的交互情況。

第一階段為容器凍結(jié)及檢查點設(shè)置階段。云計算集群中每個結(jié)點上都運行CRA，用于給容器及其任務(wù)設(shè)置檢查點文件。云計算集群中部署任務(wù)的時候，管理結(jié)點會將有關(guān)聯(lián)的任務(wù)部署到一個計算結(jié)點中，并記錄一個任務(wù)關(guān)聯(lián)表，當(dāng)云計算集群中某一結(jié)點觸發(fā)任務(wù)遷移時，由該結(jié)點的CRA 向管理結(jié)點上的檢查點恢復(fù)控制代理（checkpoint restart control agent，CRCA）發(fā)送任務(wù)遷移請求。CRCA 會根據(jù)該任務(wù)的任務(wù)關(guān)聯(lián)表向相應(yīng)的CRA發(fā)送設(shè)置檢查點命令，將設(shè)置檢查點命令分為容器記錄當(dāng)前容器的全局狀態(tài)和設(shè)置檢查點文件兩部分組成。設(shè)置檢查點命令的命令頭由任務(wù)關(guān)聯(lián)列表組成，接收到設(shè)置檢查點命令的CRA 遍歷任務(wù)關(guān)聯(lián)列表，將相應(yīng)的容器凍結(jié)并保存容器的全局狀態(tài)，并根據(jù)容器內(nèi)任務(wù)的進(jìn)程層級關(guān)系給相應(yīng)進(jìn)程設(shè)置檢查點文件。

Fig.5 Process of task migration圖5 任務(wù)遷移過程

Fig.6 Process of container migration圖6 容器遷移過程

第三階段是在遷移目的結(jié)點上的容器及任務(wù)恢復(fù)階段。容器資源管理模塊對本機(jī)資源進(jìn)行分配，給檢查點文件恢復(fù)劃分資源，并向CRA 發(fā)送重啟命令，CRA收到重啟命令后，同步任務(wù)關(guān)聯(lián)列表中的其他任務(wù)以及容器檢查點文件，根據(jù)檢查點文件內(nèi)容同時恢復(fù)容器及相應(yīng)服務(wù)。

2.4 檢查點文件傳輸方法優(yōu)化

采用InfiniBand 模型的RDMA 技術(shù)來縮短檢查點文件的傳輸時間?；赗DMA的檢查點傳輸過程如圖7所示。其中虛線箭頭為傳統(tǒng)網(wǎng)絡(luò)傳輸過程中檢查點文件的傳輸恢復(fù)過程。I/O Server為檢查點文件系統(tǒng)的數(shù)據(jù)傳輸接口服務(wù)器，用于檢查點文件的傳輸和接收。當(dāng)有服務(wù)需要回卷恢復(fù)時，系統(tǒng)選取相應(yīng)容錯主機(jī)作為服務(wù)遷移的目的結(jié)點，隨后容錯主機(jī)上的檢查點恢復(fù)模塊調(diào)用系統(tǒng)內(nèi)核的read函數(shù)，系統(tǒng)內(nèi)核向內(nèi)核模塊發(fā)送數(shù)據(jù)請求。內(nèi)核模塊向I/O Server 發(fā)送檢查點請求，I/O Server將檢查點文件加載到緩存（如圖7中的Buffer模塊所示），通過網(wǎng)絡(luò)傳輸給容錯主機(jī)內(nèi)核模塊的緩存中。隨后容錯主機(jī)的內(nèi)核模塊將檢查點文件從內(nèi)核緩存中拷貝到虛擬文件系統(tǒng)（virtual file system，VFS）的緩存頁面中（如圖7中的cache 所示），當(dāng)系統(tǒng)內(nèi)核將VFS cache 中的檢查點文件拷貝給檢查點恢復(fù)模塊的緩存中后，檢查點文件的傳輸過程結(jié)束，服務(wù)將被檢查點恢復(fù)模塊恢復(fù)。

傳統(tǒng)網(wǎng)絡(luò)傳輸過程中，檢查點文件傳輸和拷貝在文件讀取之前完成。傳輸時間包括：

Fig.7 Transport process of checkpoint based on RDMA圖7 基于RDMA的檢查點傳輸過程

（1）檢查點文件在內(nèi)核模塊Buffer 和I/O Server Buffer；

（2）內(nèi)存拷貝，從內(nèi)核模塊Buffer 拷貝到VFS cache頁面；

（3）內(nèi)存拷貝，從VFS cache 頁面?zhèn)鬏數(shù)綑z查點恢復(fù)模塊的Buffer中，其中第二個傳輸操作可以通過RDMA技術(shù)削減。

圖7中實線箭頭為采用RDMA 技術(shù)的檢查點文件傳輸方式，通過RDMA 技術(shù)可以消除冗余的內(nèi)存拷貝過程，節(jié)約了時間。通過RDMA技術(shù)，使文件傳輸像Linux內(nèi)核預(yù)讀功能一樣，在I/O Server Buffer與VFS cache頁面之間異步傳輸數(shù)據(jù)。

3 實驗測試與方法分析

面向用戶級容錯的容器遷移機(jī)制研究過程主要包括容錯池的構(gòu)建、管理過程，容錯資源的分發(fā)過程，容錯備機(jī)資源分配過程，容器遷移和恢復(fù)的全局協(xié)調(diào)過程。在實驗室環(huán)境下，對提出的容器遷移機(jī)制進(jìn)行了過程驗證，在容器環(huán)境下接收任務(wù)遷移請求的拒絕率和平均延遲，驗證容器遷移框架及相關(guān)方法的有效性和可用性。

打好污染防治攻堅戰(zhàn)時間緊、任務(wù)重、難度大，是一場大仗、硬仗、苦仗，離不開堅強(qiáng)有力的領(lǐng)導(dǎo)和紀(jì)律保障。今年以來，鹽城市紀(jì)檢監(jiān)察機(jī)關(guān)認(rèn)真貫徹習(xí)近平生態(tài)文明思想，按照中央紀(jì)委和省紀(jì)委部署，積極投身污染防治攻堅戰(zhàn)，持續(xù)強(qiáng)化環(huán)保領(lǐng)域監(jiān)督執(zhí)紀(jì)問責(zé)，有力推動全市經(jīng)濟(jì)社會實現(xiàn)綠色轉(zhuǎn)型、綠色跨越。

3.1 實驗環(huán)境設(shè)置

基于InfiniBand構(gòu)建了8個結(jié)點的網(wǎng)絡(luò)通信的小型集群模擬云計算集群。實驗拓?fù)鋱D如圖8所示。

3.2 實驗過程與性能分析

為了測試基于容器容錯池的容器遷移機(jī)制的性能，對任務(wù)遷移請求的拒絕率和平均延遲進(jìn)行了測量。分析了基于容器容錯池的容器遷移機(jī)制的實驗過程及實驗結(jié)果，通過對結(jié)果性能分析，驗證所提遷移機(jī)制的有效性和可靠性。

3.2.1 實驗過程及參數(shù)設(shè)置

實驗在不同的配置和參數(shù)設(shè)置下，測試任務(wù)遷移請求的拒絕率和總的任務(wù)恢復(fù)響應(yīng)延遲。實驗結(jié)果展示了改變?nèi)蝿?wù)遷移請求到達(dá)率、任務(wù)遷移后的剩余服務(wù)時間、容錯池中每個類型備機(jī)的數(shù)量、每個物理主機(jī)中容器數(shù)量和檢查點文件尺寸等條件取得的效果，并獲得了每個池中物理主機(jī)的穩(wěn)態(tài)分布。實驗參數(shù)范圍如表1所示。

通過腳本控制遷移源結(jié)點發(fā)送任務(wù)遷移請求來控制任務(wù)遷移請求到達(dá)率，根據(jù)容錯池的規(guī)模，將其控制為40～100之間。平均剩余服務(wù)時間為遷移任務(wù)在容錯池中的剩余運行時間，通過控制任務(wù)檢查點的設(shè)置時間和凍結(jié)容錯池中的容器的手段來改變平均剩余服務(wù)時間，控制其范圍在30～80 min。Hot、Warm、Cold 池組成了容錯池，其中Hot 池中1～3臺物理主機(jī)，Warm池中1～2臺主機(jī)，Cold池1臺主機(jī)。物理主機(jī)中容器數(shù)量為0～30個，盡管物理主機(jī)可以根據(jù)其性能容納更多的容器，但出于實驗的角度給其設(shè)置上限。Hot、Warm 池的平均查找率為各池查找空閑主機(jī)的頻率。Warm物理主機(jī)轉(zhuǎn)為Hot類型的時間為1～2 min，Cold 物理主機(jī)轉(zhuǎn)為Hot 類型的時間為2～4 min，根據(jù)實際情況而定。物理主機(jī)上容器鏡像部署時間為20～120 s，根據(jù)容器鏡像的大小變化。全局隊列可以容納20～100個任務(wù)請求。物理主機(jī)的任務(wù)隊列可以容納2～10個恢復(fù)請求。

Fig.8 Topological graph of InfiniBand cluster experiment in laboratory environment圖8 實驗室環(huán)境下InfiniBand集群實驗拓?fù)鋱D

Table 1 Range of experimental parameters表1 實驗參數(shù)范圍

遷移源結(jié)點通過Docker 容器啟動任務(wù)，并選擇所需要的進(jìn)程數(shù)，實驗中設(shè)置為兩個進(jìn)程，組成任務(wù)的進(jìn)程層級；實驗室環(huán)境下，通過事件注入的方式讓遷移源結(jié)點觸發(fā)任務(wù)遷移請求，管理結(jié)點的全局隊列接收到任務(wù)遷移請求，管理結(jié)點中的各個模塊協(xié)同工作，完成容器遷移工作。

3.2.2 任務(wù)平均剩余服務(wù)時間對系統(tǒng)性能的影響

第一組實驗研究容錯池中任務(wù)平均剩余服務(wù)時間對任務(wù)拒絕率和總延遲的影響。每個容錯備機(jī)最多可以運行30個容器。使用腳本自動發(fā)出任務(wù)遷移請求，將任務(wù)遷移請求率控制在100個請求/h，并通過掛凍結(jié)恢復(fù)任務(wù)容器的方法模擬增加任務(wù)平均剩余服務(wù)時間，恢復(fù)的任務(wù)由一個進(jìn)程組成。任務(wù)遷移請求拒絕率與任務(wù)平均剩余服務(wù)時間的關(guān)系如圖9所示。

Fig.9 Variation of rejection rate with remaining service time圖9 拒絕率隨剩余服務(wù)時間變化

圖9中4條曲線分別代表容錯池中Hot、Warm、Cold類型主機(jī)的數(shù)量，如[3，2，1]代表有3個Hot主機(jī)，2個Warm主機(jī)和1個Cold主機(jī)。隨著任務(wù)平均剩余時間的增長，任務(wù)遷移請求拒絕率成線性增長。隨著容錯池中主機(jī)數(shù)量增加，任務(wù)遷移請求拒絕率降低。無論哪種規(guī)模的容錯池，在超出其處理范圍的遷移請求到來時，經(jīng)過一定時間的處理，都會出現(xiàn)滿負(fù)荷運轉(zhuǎn)的情況，因此都會出現(xiàn)拒絕率上升的情況。但是容量大的容錯池明顯比容量小的容錯池拒絕率低。因此容錯池中容錯主機(jī)數(shù)量越大，容錯池的性能越強(qiáng)，受任務(wù)剩余服務(wù)時間影響越小。

任務(wù)恢復(fù)延遲隨任務(wù)平均剩余服務(wù)時間的關(guān)系如圖10所示。圖10中4條曲線分別代表容錯池中Hot、Warm、Cold 類型主機(jī)的數(shù)量，如[3，2，1]代表有3個Hot 主機(jī)，2個Warm 主機(jī)和1個Cold 主機(jī)。對容錯池管理來說，因為剩余服務(wù)時間直接影響隊列中檢查點文件恢復(fù)的等待時間，所以導(dǎo)致容錯池中任務(wù)剩余服務(wù)時間越長，容錯池中其他任務(wù)的恢復(fù)延遲時間就越長。在[1，1，1]這種容錯池配置下，隨著任務(wù)剩余服務(wù)時間增加，容錯池中其他任務(wù)的恢復(fù)延遲時間明顯增加，而增加容錯池中主機(jī)數(shù)量使其變?yōu)閇3，2，1]的話，任務(wù)剩余時間的增加對任務(wù)恢復(fù)延遲增加的影響不太明顯。

Fig.10 Variation of latency with remaining service time圖10 延遲隨剩余服務(wù)時間變化

3.2.3 任務(wù)遷移請求對系統(tǒng)性能的影響

實驗將任務(wù)剩余服務(wù)時間固定在40 min，并將任務(wù)遷移請求的到達(dá)率作為變量，結(jié)果如圖11所示。

當(dāng)任務(wù)遷移請求到達(dá)率達(dá)到一定程度之后，拒絕率明顯提升，這主要是由于全局隊列不足引起的。

在較低任務(wù)遷移請求到達(dá)率下任務(wù)恢復(fù)延遲急劇增加，但當(dāng)拒絕率達(dá)到一定程度之后，延遲變得平坦。這是因為高拒絕率的情況下任務(wù)恢復(fù)數(shù)量減少，因此可以通過增加全局隊列的大小的方式在高延遲情況下減少拒絕率。通過本次實驗可以看出，如果要增加云計算集群容錯的性能，減少任務(wù)恢復(fù)等待時間和任務(wù)遷移拒絕率，可以采取以下措施：（1）增加容錯池的容量，即增加容錯備機(jī)的數(shù)量來減少任務(wù)恢復(fù)等待時間。（2）根據(jù)延遲情況增加全局隊列大小來減少拒絕率。如圖12所示。

Fig.11 Variation of rejection rate with arrival rate of migration request圖11 拒絕率隨遷移請求到達(dá)率變化

Fig.12 Variation of latency with arrival rate of migration request圖12 延遲隨遷移請求到達(dá)率變化

3.2.4 池查找率對系統(tǒng)性能的影響

池查找率是容器管理模塊查找空閑Hot 備機(jī)并將其轉(zhuǎn)為Warm 或Cold 類型的頻率。Hot 備機(jī)先被轉(zhuǎn)為Warm 類型，然后轉(zhuǎn)為Cold 類型，如果Warm 池中主機(jī)數(shù)量達(dá)到閾值，Hot將直接轉(zhuǎn)變?yōu)镃old。之前的實驗中，平均查找率控制在4次/h。雖然更高的池查找率將降低能量消耗，但是查找率高容易引起pingpong 效應(yīng)，即一個最近關(guān)閉的備機(jī)可能很快又被重新啟動，導(dǎo)致備機(jī)在Hot、Warm、Cold 池中頻繁轉(zhuǎn)換類型。備機(jī)頻繁轉(zhuǎn)換類型可能增加延遲和拒絕概率。

圖13展示了池查找率對任務(wù)遷移請求拒絕率的影響。從圖13中可以看出，容錯池中備機(jī)越多任務(wù)遷移請求拒絕率越低，對于[1，1，1]容量的容錯池，查找率在3次/h拒絕率最低。對于不同容量的容錯池，在拒絕率最低的情況下，隨著容錯池容量的增加，查找率遞減。對于[3，2，1]容量的容錯池，查找率的改變對拒絕率影響較小。

Fig.13 Variation of rejection rate with pool lookup rate圖13 拒絕率隨池查找率變化

圖14展示了池查找率對任務(wù)恢復(fù)延遲的影響。從圖14中可以看出，容錯池中備機(jī)越多任務(wù)恢復(fù)延遲越小，對于[1，1，1]容量的容錯池，查找率在3次/h拒絕率最低。對于不同容量的容錯池，達(dá)到最低任務(wù)恢復(fù)延遲的情況下，隨著容錯池容量的增加，查找率遞減。對于[3，2，1]容量的容錯池，查找率的改變對拒絕率影響很小。

Fig.14 Variation of latency with pool lookup rate圖14 延遲隨池查找率變化

4 結(jié)束語

為應(yīng)對虛擬化云計算集群可靠性所面臨的嚴(yán)峻挑戰(zhàn)，在傳統(tǒng)集群容錯和虛擬機(jī)容錯的基礎(chǔ)上，引入容器虛擬化技術(shù)，將傳統(tǒng)的物理容錯備機(jī)虛擬成容錯資源池，提出一種有效的云計算集群中基于容器的容錯資源分配過程和優(yōu)化辦法。然而，如何對容錯資源的動態(tài)性進(jìn)行建模，從而泛化容錯資源分配過程和優(yōu)化手段，仍然是未來亟待解決的重點問題之一。此外，目前針對容器遷移機(jī)制的研究主要在進(jìn)程遷移技術(shù)上，如何利用容器啟動和關(guān)閉快速的特點優(yōu)化其遷移機(jī)制，仍然是未來的研究重點之一。