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

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

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

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

1 引言

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

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

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

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

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

2.1 容器遷移框架和容器容錯(cuò)池框架

2.1.1 容器遷移原理

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

值得注意的是，傳統(tǒng)的虛擬機(jī)熱遷移是通過定期將內(nèi)存頁從源主機(jī)復(fù)制到目的主機(jī)來實(shí)現(xiàn)，數(shù)據(jù)中心的管理平臺(tái)根據(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ī)，可減少遷移時(shí)間[13-15]。

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

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

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

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

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

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

2.1.3 容器容錯(cuò)池框架及自動(dòng)伸縮策略

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

其中，容錯(cuò)資源管理器負(fù)責(zé)容錯(cuò)備機(jī)的管理，管理器由Hot、Warm、Cold 代理組成，分別負(fù)責(zé)Hot、Warm、Cold 類型主機(jī)的資源配置和容錯(cuò)備機(jī)類型的轉(zhuǎn)換，如Cold 代理開啟Cold 主機(jī)并加載容器鏡像使其變?yōu)镠ot 主機(jī)。當(dāng)容器容錯(cuò)池中有容器容錯(cuò)資源請(qǐng)求到來時(shí)，容錯(cuò)資源管理器首先將請(qǐng)求發(fā)送給Hot代理，如果Hot 池中有合適的備機(jī)，即具有容器鏡像的備機(jī)且備機(jī)資源足夠恢復(fù)任務(wù)，則Hot代理直接控制該備機(jī)恢復(fù)相應(yīng)的任務(wù)遷移請(qǐng)求。如果Hot 類型池中的備機(jī)不具備相應(yīng)的資源來恢復(fù)任務(wù)，則Hot代理將請(qǐng)求轉(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 代理將請(qǐng)求轉(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 容器容錯(cuò)池框架

容錯(cuò)池中，每臺(tái)運(yùn)行恢復(fù)任務(wù)的主機(jī)要保持主機(jī)內(nèi)存負(fù)載在70%以下，帶寬負(fù)載在30%以下。Hot池中至少保持一臺(tái)主機(jī)內(nèi)存負(fù)載在70%以下，帶寬負(fù)載在30%以下。Warm 池根據(jù)設(shè)置維持臺(tái)主機(jī)，剩余容錯(cuò)主機(jī)處于關(guān)機(jī)狀態(tài)，被Cold池管理。當(dāng)有Hot型主機(jī)上所有服務(wù)都運(yùn)行完畢后，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ì)算主機(jī)，不作為容錯(cuò)資源，從而節(jié)約資源，也可以被激活并下載相應(yīng)容器鏡像，成為Hot類型備機(jī)。

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

2.2.1 容器檢查點(diǎn)重啟方法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一旦進(jìn)程層級(jí)被恢復(fù)，所有的進(jìn)程通過重啟系統(tǒng)，根據(jù)檢查點(diǎn)順序在內(nèi)核中恢復(fù)。在CRA 的協(xié)助下，遷移任務(wù)進(jìn)程層級(jí)下的子進(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讓第一個(gè)進(jìn)程開始恢復(fù)，并等待所有進(jìn)程都被恢復(fù)。最后，CRA通知任務(wù)恢復(fù)正常運(yùn)行，并從系統(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)。然后各個(gè)進(jìn)程按照進(jìn)程恢復(fù)層級(jí)的順序依次運(yùn)行，從檢查點(diǎn)文件中獲取狀態(tài)，并通知下一個(gè)進(jìn)程開始恢復(fù)，并等待CRA的正常運(yùn)行通知。當(dāng)所有進(jìn)程成功地恢復(fù)相應(yīng)狀態(tài)后，遷移任務(wù)可以成功運(yùn)行。

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

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

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

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

2.3 容器遷移流程

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

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

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

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

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

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

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

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

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

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

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

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

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

3 實(shí)驗(yàn)測(cè)試與方法分析

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

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

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

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

3.2 實(shí)驗(yàn)過程與性能分析

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

3.2.1 實(shí)驗(yàn)過程及參數(shù)設(shè)置

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2.4 池查找率對(duì)系統(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。之前的實(shí)驗(yàn)中，平均查找率控制在4次/h。雖然更高的池查找率將降低能量消耗，但是查找率高容易引起pingpong 效應(yīng)，即一個(gè)最近關(guān)閉的備機(jī)可能很快又被重新啟動(dòng)，導(dǎo)致備機(jī)在Hot、Warm、Cold 池中頻繁轉(zhuǎn)換類型。備機(jī)頻繁轉(zhuǎn)換類型可能增加延遲和拒絕概率。

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

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

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

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

4 結(jié)束語

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