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

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

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

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

1 引言

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

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

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

2 基于容器容錯池的容器遷移機制

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

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

2.1.1 容器遷移原理

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2 檢查點和回卷機制

2.2.1 容器檢查點重啟方法

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

Fig.4 Theory of PID-Namespaces圖4 進程編號-命名空間原理

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

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

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

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

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

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

（5）解凍任務(wù)層級下的所有進程使任務(wù)繼續(xù)運行，或者終止所有進程以便進行任務(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)存標識符；

（2）/proc/pid/pagemap文件中重要的標識符；

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

恢復檢查點過程如下：

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

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

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

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

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

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

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

2.2.2 容器遷移回卷機制

云計算中心中可以運行各種各樣的服務(wù)。針對科學計算程序，如消息傳遞接口（message passing interface，MPI）程序，對服務(wù)的持續(xù)性要求較高，周期性設(shè)置檢查點就可以滿足保存服務(wù)狀態(tài)，減少系統(tǒng)崩潰對服務(wù)造成的損失。對于Web 服務(wù)等實時服務(wù)，一旦服務(wù)回卷，將會降低用戶體驗。同時，Web服務(wù)通常通過cookie 和session 機制保存用戶狀態(tài)，并結(jié)合服務(wù)集群的方式進行服務(wù)容錯。每個Web請求只有幾秒中的時間，不適用檢查點文件來保存服務(wù)器程序的狀態(tài)?？梢钥闯觯鼐頇C制主要針對耗時較長的計算程序，對這類程序可進行有效的檢查點設(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ù)從源主機遷移到容錯主機上，C/R 管理器通過T1時刻設(shè)置的檢查點文件t1在容錯主機上恢復了服務(wù)，此時服務(wù)的狀態(tài)是t1，源主機上的服務(wù)被主動或被迫終止。此時服務(wù)的狀態(tài)為t1，服務(wù)發(fā)生回卷，回卷過程中服務(wù)丟失了T3時刻到T2時刻之間的狀態(tài)。如果服務(wù)只由一個進程組成，這種回卷對服務(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é)同回卷機制，管理結(jié)點上的遷移管理模塊會將有關(guān)聯(lián)的服務(wù)列入一個同步表中，當給處在某一關(guān)聯(lián)中的一個服務(wù)設(shè)置檢查點時，遷移管理模塊向同步表中所有服務(wù)發(fā)送控制信息，同步檢查點的設(shè)置。當恢復服務(wù)時，同步表中的服務(wù)同時恢復。

2.3 容器遷移流程

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

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

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

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

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

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

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

傳統(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查點恢復模塊的Buffer中，其中第二個傳輸操作可以通過RDMA技術(shù)削減。

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

3 實驗測試與方法分析

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

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

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

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

3.2 實驗過程與性能分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 結(jié)束語

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