趙 旭 李艷梅 羅 建 羅金梅

云服務(wù)[1]是一種當(dāng)下熱門的互聯(lián)網(wǎng)模型,它將軟硬件資源進(jìn)行整合,以虛擬環(huán)境和裸機(jī)環(huán)境兩種方式為用戶提供對(duì)象存儲(chǔ)、容量型、性能型等存儲(chǔ)和計(jì)算功能.一方面,云平臺(tái)可以隱藏復(fù)雜硬件特征,用戶無需具備專業(yè)計(jì)算機(jī)軟、硬資源知識(shí)即可使用,這種特性大大降低了個(gè)體運(yùn)維成本;另一方面,虛擬技術(shù)為用戶應(yīng)用提供了獨(dú)占資源環(huán)境,可避免由資源共享帶來的干擾[2-3].然而,隨著部署于云中的應(yīng)用數(shù)量以及規(guī)模的急劇擴(kuò)張,云服務(wù)面臨著一個(gè)難以忽視的高能耗問題.在這種場(chǎng)景下,在線遷移技術(shù)應(yīng)時(shí)而生,它可將應(yīng)用在云中適時(shí)聚合與分離,實(shí)現(xiàn)能耗可控性,進(jìn)而成為當(dāng)下的研究熱點(diǎn)之一.深入研究有效的云端管理平臺(tái)將對(duì)控制理論的發(fā)展和各種實(shí)際應(yīng)用起到積極推動(dòng)的作用[4-5].

與裸機(jī)在線遷移技術(shù)不同,云進(jìn)程在線遷移成本主要受兩方面的影響: 虛擬執(zhí)行環(huán)境和任務(wù)執(zhí)行環(huán)境.虛擬執(zhí)行環(huán)境由應(yīng)用執(zhí)行所必須的虛擬機(jī)構(gòu)成;任務(wù)執(zhí)行環(huán)境則包括任務(wù)自身執(zhí)行狀態(tài),所需輸入、輸出數(shù)據(jù)等.當(dāng)前云服務(wù)平臺(tái)最主流的幾種執(zhí)行環(huán)境為KVM[6],VMware[7]和Xen[8].然而在遷移場(chǎng)景下,由于程序運(yùn)行局部性和磁盤I/O (Input/output)讀寫局限性原理,導(dǎo)致記錄磁盤的寫操作會(huì)有較多的冗余,它們高昂的管理開銷、繁冗的管理層次更成為阻礙其發(fā)展的主要缺陷[9-10].鑒于虛擬機(jī)環(huán)境上述特征并不適于為大數(shù)據(jù)應(yīng)用提供服務(wù),虛擬執(zhí)行環(huán)境自身開銷過高嚴(yán)重影響了在線遷移效率,而輕量級(jí)容器利用自身低開銷可以降低遷移系統(tǒng)自身的數(shù)據(jù)成本,滿足當(dāng)前企業(yè)需求——高效、節(jié)能.因此,基于輕量級(jí)容器的遷移策略成為云服務(wù)相關(guān)技術(shù)中所急需的研究?jī)?nèi)容之一.

Docker[11]是目前熱門的容器技術(shù)之一,如圖1所示,根據(jù)最新RightScale[12]云計(jì)算調(diào)查報(bào)告顯示Docker 的采用率從2017 年的35%增長(zhǎng)到了2018年的49% (增長(zhǎng)率為40%).作為一款輕量級(jí)開源容器引擎,有能力簡(jiǎn)化和快速部署應(yīng)用隔離環(huán)境,完成云平臺(tái)不同企業(yè)應(yīng)用之間的“隔離”需求.

圖1 2018 年RightScale 云計(jì)算調(diào)查報(bào)告Fig.1 RightScale cloud survey report of 2018

在圖2 中,分別對(duì)比了KVM 和Docker 的執(zhí)行開銷,具體的實(shí)驗(yàn)是以內(nèi)存帶寬基準(zhǔn)測(cè)試程序Stream 的Copy,Scale,Add 和Traid 四個(gè)組件為例.橫坐標(biāo)分別代表內(nèi)存占用為20～800 MB,縱坐標(biāo)分別代表Stream 四個(gè)組件隨著臟頁速率變化各自的數(shù)據(jù)處理能力.實(shí)驗(yàn)結(jié)果表明,對(duì)于內(nèi)存密集型程序而言,KVM 自身執(zhí)行環(huán)境比Docker 自身執(zhí)行環(huán)境多出了20%以上的開銷.內(nèi)存計(jì)算型任務(wù)的遷移成本是影響在線遷移效率的另一個(gè)重要因素,將龐大的應(yīng)用數(shù)據(jù)遷入內(nèi)存,降低與外設(shè)交互所引發(fā)的開銷是實(shí)現(xiàn)大數(shù)據(jù)應(yīng)用高效執(zhí)行的重要手段.然而,在動(dòng)態(tài)遷移的場(chǎng)景下,龐大的內(nèi)存數(shù)據(jù)遷移會(huì)帶來高昂的遷移開銷.

圖2 Stream 測(cè)試KVM 和Docker 開銷Fig.2 Stream testing for KVM and Docker overheads

總的來說,云端虛擬機(jī)遷移的成本主要源于兩方面,即虛擬機(jī)自身開銷和用戶應(yīng)用所占據(jù)的資源開銷.單純對(duì)某一方面進(jìn)行管控,都無法明顯降低遷移成本.根據(jù)對(duì)比Docker 和KVM 測(cè)試Stream發(fā)現(xiàn),Docker 技術(shù)已顯著減少了虛擬機(jī)自身開銷,但仍然無法滿足內(nèi)存密集型或者大數(shù)據(jù)應(yīng)用動(dòng)態(tài)遷移的成本需求.實(shí)際上,諸如華為、阿里等主流云服務(wù)提供商對(duì)于動(dòng)態(tài)遷移所產(chǎn)生的時(shí)刻和所遷往的目標(biāo)都有明確的管理方法,只要科學(xué)采用這些信息,充分利用云平臺(tái)的閑置資源,提前將一部分必須且穩(wěn)定的數(shù)據(jù)放在云端存儲(chǔ)上,那么將顯著降低宿主機(jī)的數(shù)據(jù)規(guī)模,減少宿主機(jī)在后續(xù)遷移過程中的開銷.此外,待遷移開始之后,利用網(wǎng)絡(luò)并行性,宿主機(jī)和云端存儲(chǔ)同時(shí)將各自數(shù)據(jù)遷移至指定目的主機(jī),在線遷移將同時(shí)獲益于宿主機(jī)數(shù)據(jù)規(guī)模縮小以及網(wǎng)絡(luò)并行性.

本文提出一種新的基于云預(yù)存儲(chǔ)技術(shù)的Docker 在線遷移方法: PF-Docker,該方法將預(yù)存技術(shù)與成熟的Pre-copy 技術(shù)相結(jié)合,充分利用云平臺(tái)的網(wǎng)絡(luò)和存儲(chǔ)資源,實(shí)現(xiàn)高效在線遷移.PF-Docker 在應(yīng)用程序平穩(wěn)運(yùn)行時(shí),將動(dòng)態(tài)搜集用戶數(shù)據(jù)行為,并將穩(wěn)定數(shù)據(jù)預(yù)存至閑置的網(wǎng)絡(luò)存儲(chǔ)資源上.待在線遷移啟動(dòng),宿主機(jī)將對(duì)剩余數(shù)據(jù)實(shí)施基于Pre-copy 的在線遷移,而云存儲(chǔ)中的數(shù)據(jù)將同時(shí)向目標(biāo)機(jī)進(jìn)行傳輸.PF-Docker 明顯受益于縮小的宿主機(jī)數(shù)據(jù)規(guī)模以及云平臺(tái)中豐富的網(wǎng)絡(luò)存儲(chǔ)并行性.實(shí)驗(yàn)結(jié)果說明,相對(duì)于現(xiàn)有容器遷移方法,本文方法在不同類型的服務(wù)負(fù)載下均能正確執(zhí)行.對(duì)于空負(fù)載的Docker 容器,本方法對(duì)比文獻(xiàn)[13]中的遷移方法降低了25%的數(shù)據(jù)成本;在高負(fù)載寫密集環(huán)境下,本方法降低了15%的數(shù)據(jù)成本遷移和減少了總傳輸時(shí)間11%;在服務(wù)降級(jí)率方面,本文Docker動(dòng)態(tài)遷移框架比KVM 動(dòng)態(tài)遷移更加穩(wěn)定.

本文主要貢獻(xiàn)如下:

1)云服務(wù)和預(yù)存儲(chǔ)結(jié)合的動(dòng)態(tài)遷移策略.在遷移命令下達(dá)之前,在云端尋找空閑服務(wù)器作為數(shù)據(jù)管理平臺(tái),宿主機(jī)在特定條件下將容器動(dòng)態(tài)遷移的穩(wěn)定數(shù)據(jù)預(yù)存儲(chǔ)到云端存儲(chǔ);在遷移命令下達(dá)之后,云端存儲(chǔ)與宿主機(jī)利用網(wǎng)絡(luò)并行性同時(shí)向目的機(jī)傳輸數(shù)據(jù).

2)輕量級(jí)容器Docker 動(dòng)態(tài)預(yù)存儲(chǔ)遷移框架.采用預(yù)存儲(chǔ)、迭代傳輸和檢查點(diǎn)恢復(fù)機(jī)制相結(jié)合的方式,減少迭代次數(shù)與傳輸時(shí)間,實(shí)現(xiàn)輕量級(jí)容器Docker 動(dòng)態(tài)預(yù)存儲(chǔ)遷移.

3)引入限定預(yù)存儲(chǔ)閾值觸發(fā)策略.設(shè)定服務(wù)器預(yù)負(fù)載的上限,判斷運(yùn)行Docker 容器的服務(wù)器是否滿足預(yù)存儲(chǔ)的條件,防止預(yù)存儲(chǔ)無效占用云端資源.

1 相關(guān)工作研究

遷移技術(shù)一直是云計(jì)算研究的重點(diǎn),針對(duì)云端虛擬機(jī)環(huán)境動(dòng)態(tài)遷移,目前國(guó)內(nèi)外已經(jīng)有了許多相關(guān)的研究和方案.Collective 項(xiàng)目比較早地支持了虛擬機(jī)在線遷移,主要是面向無實(shí)時(shí)性和不確定性的服務(wù),為需要遷移計(jì)算程序的用戶提供了便利[14].Kozuch 等[15]提出了一種采用Freeze-and-Copy 的虛擬機(jī)在線遷移方法.Clark 等[16]提出了一種采用Pre-copy 內(nèi)存遷移算法的虛擬機(jī)動(dòng)態(tài)遷移機(jī)制,目前基于Pre-copy 算法的虛擬機(jī)動(dòng)態(tài)遷移已經(jīng)得到廣泛使用,當(dāng)前流行的虛擬化工具如KVM、Xen和VMware 都提供基于Pre-copy 算法的虛擬機(jī)動(dòng)態(tài)遷移機(jī)制.清華大學(xué)周佳祥等[17]提出采用自適應(yīng)雙閾值進(jìn)程動(dòng)態(tài)遷移負(fù)載平衡系統(tǒng).北京大學(xué)張彬彬等[18]提出了一種三階段全系統(tǒng)動(dòng)態(tài)遷移算法TPM (Three-phase migration).中國(guó)科學(xué)技術(shù)大學(xué)邵曦煜[19]提出了非共享存儲(chǔ)的Ceph 虛擬機(jī)動(dòng)態(tài)遷移系統(tǒng).吉林大學(xué)趙佳[20]提出了一種新的高效遷移機(jī)制——HMDC 和FMC.北京航天航空大學(xué)的呂小虎等[21]也提出了一種基于虛擬機(jī)磁盤的動(dòng)態(tài)遷移機(jī)制.

雖然業(yè)界對(duì)于虛擬化動(dòng)態(tài)遷移技術(shù)已經(jīng)有了很多的研究成果,但針對(duì)容器動(dòng)態(tài)遷移的相關(guān)研究仍處于起步階段.Zap 作為一個(gè)進(jìn)程遷移的典型系統(tǒng),其設(shè)計(jì)目標(biāo)是在網(wǎng)絡(luò)計(jì)算體系結(jié)構(gòu)下支持可遷移的計(jì)算環(huán)境,但本身不支持動(dòng)態(tài)遷移[22].OpenVZ 是目前容器遷移技術(shù)中相對(duì)成熟的技術(shù)之一,通過修改內(nèi)核來達(dá)到虛擬化的目的,利用檢查點(diǎn)恢復(fù)機(jī)制支持容器的動(dòng)態(tài)遷移.但OpenVZ 本質(zhì)是基于Linux內(nèi)核和作業(yè)系統(tǒng)的操作系統(tǒng)虛擬化技術(shù),和主流容器技術(shù)有很大的區(qū)別,動(dòng)態(tài)遷移效率和傳統(tǒng)虛擬機(jī)差別不大,且主要問題在于OpenVZ 只能使用經(jīng)過特定補(bǔ)丁的內(nèi)核.相比之下,Docker 容器技術(shù)直接從Linux 內(nèi)核進(jìn)行虛擬化,具有很大的優(yōu)勢(shì).針對(duì)容器遷移問題,可以借助于進(jìn)程組遷移原理來解決,已有一些相關(guān)的開源工具和項(xiàng)目支持容器進(jìn)程組遷移,具體如CRIU[23],P.Haul[24].Docker 官方目前只支持離線遷移,對(duì)于無狀態(tài)容器,遷移的過程為備份和恢復(fù).電子科技大學(xué)禹超[25]提出基于Linux 容器的同步遷移文件系統(tǒng)機(jī)制FFSAS,根據(jù)監(jiān)控并記錄Linux 是容器對(duì)文件系統(tǒng)的修改,將更改信息通過五元組的形式保存在高速緩存中,最后同步到目的機(jī),減少整個(gè)遷移過程中的傳輸數(shù)據(jù)量,但是這種機(jī)制很大程度上僅僅針對(duì)文件系統(tǒng)進(jìn)程,對(duì)于高負(fù)載寫密集環(huán)境的云應(yīng)用并不適用.中國(guó)科學(xué)院大學(xué)胡丹琪[13]提出基于容器內(nèi)部檢查點(diǎn)恢復(fù)機(jī)制的Docker 容器整體遷移框架,通過runC 調(diào)用CRIU來實(shí)現(xiàn)相應(yīng)功能,避免了P.Haul 等工具遷移完成后需要重啟Docker 守護(hù)進(jìn)程的限制,但是忽視了容器內(nèi)部系統(tǒng)數(shù)據(jù),導(dǎo)致傳輸?shù)臄?shù)據(jù)量和總傳輸時(shí)間依舊很高.

從降低開銷的角度考慮容器動(dòng)態(tài)遷移問題,減少數(shù)據(jù)傳輸和優(yōu)化遷移算法都是正確的選擇之一[26-27],但不同的應(yīng)用場(chǎng)景和環(huán)境可能需要采用不同的策略和方法.以內(nèi)存程序?yàn)槔? 不同源主機(jī)容器中運(yùn)行程序的內(nèi)存文件所占比例并不可控,因此內(nèi)存程序的傳輸能耗標(biāo)準(zhǔn)并不一致,選擇合適的方法并不容易.對(duì)于本文中提出的Docker 容器動(dòng)態(tài)遷移策略,實(shí)驗(yàn)發(fā)現(xiàn)減少源主機(jī)的傳輸數(shù)據(jù)量能直觀感受到數(shù)據(jù)傳輸開銷的降低.采用云服務(wù)和預(yù)存儲(chǔ)相結(jié)合的方式有利于降低整個(gè)動(dòng)態(tài)遷移過程的性能影響、開銷和提高數(shù)據(jù)傳輸效率.

2 PF-Docker 基于預(yù)存儲(chǔ)的動(dòng)態(tài)遷移方法

本文提出基于云預(yù)存的PF-Docker 算法,用于解決云服務(wù)器中的高能耗、高負(fù)載和管理難等問題,算法采用動(dòng)態(tài)預(yù)存技術(shù)和成熟的Pre-copy 技術(shù),以減少Docker 容器動(dòng)態(tài)遷移過程中宿主機(jī)的傳輸數(shù)據(jù)量,并充分利用云服務(wù)網(wǎng)絡(luò)和存儲(chǔ)等資源來實(shí)現(xiàn)高效的Docker 容器在線遷移.具體流程如圖3 所示.PF-Docker 主要由兩部分構(gòu)成: 動(dòng)態(tài)云預(yù)存和動(dòng)態(tài)迭代遷移.當(dāng)服務(wù)器和內(nèi)部應(yīng)用程序的運(yùn)行狀態(tài)趨于穩(wěn)定時(shí),PF-Docker 自動(dòng)進(jìn)入到動(dòng)態(tài)云預(yù)存階段,此階段會(huì)定時(shí)動(dòng)態(tài)搜集兩種必要信息: 應(yīng)用程序數(shù)據(jù)行為和服務(wù)器運(yùn)行數(shù)據(jù)狀況.根據(jù)對(duì)運(yùn)行在不同宿主機(jī)上的Docker 容器應(yīng)用程序和宿主機(jī)本身運(yùn)行狀態(tài)進(jìn)行采樣分析,重點(diǎn)針對(duì)Docker 容器自身掛載文件和內(nèi)部應(yīng)用程序輸出數(shù)據(jù)等穩(wěn)定的數(shù)據(jù)文件,結(jié)合宿主機(jī)的CPU 使用率、帶寬傳輸比例和內(nèi)存占比,將符合條件的穩(wěn)定數(shù)據(jù)文件(流動(dòng)數(shù)據(jù))動(dòng)態(tài)預(yù)存至指定的處于空閑狀態(tài)的網(wǎng)絡(luò)存儲(chǔ)資源上;將不符合條件的數(shù)據(jù)(冗余數(shù)據(jù))留在各自的宿主機(jī)上.這兩類數(shù)據(jù)呈正交,彼此互斥,共同組成了完整的程序運(yùn)行數(shù)據(jù)空間.當(dāng)用戶需要對(duì)服務(wù)器進(jìn)行維護(hù)時(shí),PF-Docker 根據(jù)相關(guān)的命令進(jìn)入到動(dòng)態(tài)迭代遷移階段,它同時(shí)驅(qū)動(dòng)宿主機(jī)和云端存儲(chǔ)器向目標(biāo)主機(jī)進(jìn)行在線遷移.網(wǎng)絡(luò)目標(biāo)機(jī)將對(duì)流動(dòng)數(shù)據(jù)和部分冗余數(shù)據(jù)實(shí)施網(wǎng)絡(luò)并行傳輸,宿主機(jī)將對(duì)剩余冗余數(shù)據(jù)實(shí)施基于Pre-copy 的動(dòng)態(tài)迭代遷移,以此保證云服務(wù)網(wǎng)絡(luò)和存儲(chǔ)的利用最大化,實(shí)現(xiàn)高效的Docker 容器的動(dòng)態(tài)遷移.

2.1 動(dòng)態(tài)云預(yù)存

與傳統(tǒng)數(shù)據(jù)預(yù)存技術(shù)[28]不同,動(dòng)態(tài)云預(yù)存技術(shù)通過階段性對(duì)宿主機(jī)內(nèi)部Docker 應(yīng)用程序的執(zhí)行狀態(tài)進(jìn)行學(xué)習(xí)和分析,選擇符合某種特性的穩(wěn)定數(shù)據(jù),將其在動(dòng)態(tài)遷移之前預(yù)先傳輸至云端存儲(chǔ).如圖4 所示.根據(jù)對(duì)容器動(dòng)態(tài)遷移進(jìn)行實(shí)驗(yàn)分析,發(fā)現(xiàn)在遷移過程的每次迭代時(shí)間開銷主要由遍歷、壓縮和傳輸三部分構(gòu)成.其中遍歷是指對(duì)應(yīng)用程序所占內(nèi)存頁狀態(tài)的遍歷時(shí)間開銷;壓縮是指在迭代傳輸期間一次迭代中壓縮臟頁和其他已變化信息的時(shí)間開銷;傳輸是指在迭代傳輸期間一次迭代中傳輸壓縮數(shù)據(jù)的時(shí)間成本.在容器動(dòng)態(tài)遷移的每次迭代過程中,對(duì)冗余數(shù)據(jù)的遍歷結(jié)果重點(diǎn)分為已變化和無變化兩種,而傳輸階段所傳輸數(shù)據(jù)主要為臟頁和進(jìn)程輸出信息等已變化的運(yùn)行數(shù)據(jù),進(jìn)一步分析發(fā)現(xiàn),在這三個(gè)階段中遍歷和壓縮的時(shí)間開銷是影響迭代周期設(shè)置的重要因素.而對(duì)于大數(shù)據(jù)應(yīng)用而言,遍歷與壓縮的成本會(huì)嚴(yán)重增加迭代周期,進(jìn)而影響容器的整體遷移時(shí)間.在已有的研究成果中[29],采取將壓縮算法結(jié)合入遷移過程.目前,采用諸如LZ4[30]等最佳壓縮算法可以將數(shù)據(jù)壓縮到1%.這個(gè)壓縮比能大大減少迭代數(shù)據(jù)的傳輸量,以此迅速完成數(shù)據(jù)的傳輸.本文后續(xù)將使用LZ4 作為標(biāo)準(zhǔn)壓縮算法.在壓縮算法的配合下,傳輸開銷的分量將明顯降低,甚至可被忽略.其中迭代遷移的開銷計(jì)算方式如下

其中,Titer表示迭代傳輸階段時(shí)間間隔;Ttravs表示在迭代期間一次遍歷所有內(nèi)存頁的時(shí)間成本,與進(jìn)程所占內(nèi)存大小密切相關(guān);Tcomp表示在迭代期間一次迭代中壓縮臟頁的時(shí)間成本,與進(jìn)程所占內(nèi)存大小相關(guān).基于上述分析,為了保證高效的網(wǎng)絡(luò)傳輸和數(shù)據(jù)的均衡性,本文根據(jù)對(duì)程序運(yùn)行過程中的數(shù)據(jù)更改情況進(jìn)行學(xué)習(xí)分析,如式(2)所示,在特定周期內(nèi),數(shù)據(jù)修改頻率大于這段時(shí)間的迭代次數(shù),那么將這種數(shù)據(jù)定義為穩(wěn)定數(shù)據(jù),執(zhí)行預(yù)存?zhèn)鬏?

為了描述這一問題,本文對(duì)預(yù)存數(shù)據(jù)進(jìn)行如下定義: 宿主機(jī)容器和內(nèi)部進(jìn)程數(shù)據(jù)單次修改頻率為C,那么n次數(shù)據(jù)修改頻率為η=當(dāng)?shù)鷤鬏敶螖?shù)小于數(shù)據(jù)修改率η時(shí),滿足預(yù)存數(shù)據(jù)的定義,進(jìn)行有效的預(yù)存?zhèn)鬏?

遷移總數(shù)據(jù)包含預(yù)存數(shù)據(jù)和宿主機(jī)數(shù)據(jù),而預(yù)存數(shù)據(jù)量與宿主機(jī)數(shù)據(jù)量成反比,預(yù)存數(shù)據(jù)量越多,則留在宿主機(jī)的數(shù)據(jù)量越少,網(wǎng)絡(luò)傳輸和云存儲(chǔ)的利用率也就越高.如圖5 所示,預(yù)存數(shù)據(jù)分為Docker容器環(huán)境依賴和進(jìn)程的數(shù)據(jù)文件,其中Docker 容器環(huán)境依賴包括基礎(chǔ)鏡像、子系統(tǒng)文件和掛載數(shù)據(jù),進(jìn)程的數(shù)據(jù)文件包括應(yīng)用的內(nèi)存頁、程序輸出數(shù)據(jù)和進(jìn)程執(zhí)行信息.分析發(fā)現(xiàn)Docker 容器的環(huán)境依賴文件基本不會(huì)發(fā)生變化,可以直接傳給云端存儲(chǔ)器;而進(jìn)程的數(shù)據(jù)文件會(huì)隨著程序的運(yùn)行發(fā)生改變,這時(shí)需要采用動(dòng)態(tài)預(yù)存算法對(duì)該部分?jǐn)?shù)據(jù)文件進(jìn)行分類處理,尋找出符合條件的預(yù)存數(shù)據(jù),再傳給云端存儲(chǔ)器.具體的預(yù)存?zhèn)鬏斶^程分為以下兩部分:

圖5 動(dòng)態(tài)云預(yù)存?zhèn)鬏斄鞒虉DFig.5 Dynamic cloud pre-storage transfer flowchart

1)在宿主機(jī)和云端存儲(chǔ)平臺(tái)之間建立socket通信管道,用于預(yù)存數(shù)據(jù)的傳輸;

2)利用Docker 本身提供的inspect 接口實(shí)現(xiàn)相關(guān)函數(shù)的調(diào)用,獲取與容器相關(guān)的數(shù)據(jù)信息,將Docker 容器運(yùn)行所需的基礎(chǔ)鏡像、掛載數(shù)據(jù)、子系統(tǒng)文件和其他穩(wěn)定的數(shù)據(jù)信息預(yù)存儲(chǔ)到云端存儲(chǔ)平臺(tái),等待容器動(dòng)態(tài)遷移命令下達(dá).

在利用云預(yù)存儲(chǔ)技術(shù)實(shí)現(xiàn)容器動(dòng)態(tài)遷移的前提下,為避免對(duì)宿主機(jī)容器進(jìn)程的重復(fù)采樣分析影響進(jìn)程的自身執(zhí)行情況,本文采用限定閾值的方法來確定宿主機(jī)是否滿足預(yù)存儲(chǔ)的條件.基于限定閾值的PF-Docker 遷移方法需要綜合考慮宿主機(jī)CPU、帶寬、內(nèi)存資源的利用率.

宿主機(jī)的CPU 使用率為

其中,Vdi表示單個(gè)Docker 容器在單個(gè)CPU中的使用率,表示單個(gè)CPU在該物理節(jié)點(diǎn)所有Docker 容器di中使用率,Scpu表示該物理服務(wù)器總的CPU 使用率.

宿主機(jī)的帶寬使用率為

其中,Dbw(i)表示Docker 容器di在該物理節(jié)點(diǎn)的帶寬使用情況;Tbw表示該物理節(jié)點(diǎn)帶寬流量的最大值.

宿主機(jī)的內(nèi)存使用率為

其中,Dmem(i)表示Docker 容器di在該物理節(jié)點(diǎn)使用的內(nèi)存大小;Amem表示該物理節(jié)點(diǎn)總的內(nèi)存大小.云服務(wù)器節(jié)點(diǎn)的CPU、帶寬、內(nèi)存等資源的使用率可以用一個(gè)向量集合Pcoc=(Pcpu,Pmem,Pbw)表示.

通過預(yù)存儲(chǔ)閾值設(shè)定算法的檢測(cè),重點(diǎn)獲取當(dāng)前服務(wù)器中Docker 容器內(nèi)部任務(wù)的運(yùn)行狀況,主要具有以下兩點(diǎn)優(yōu)勢(shì):

1)動(dòng)態(tài)調(diào)控.目前主流的任務(wù)類型主要分為:計(jì)算密集型、內(nèi)存密集型、多線程執(zhí)行等.用戶首先可以根據(jù) Docker 容器內(nèi)部執(zhí)行任務(wù)的類型來設(shè)定預(yù)存閾值的大小;其次在保證任務(wù)正常運(yùn)行的情況下,根據(jù)主機(jī)之間的資源利用情況來調(diào)控預(yù)存閾值的大小,保證資源的充分利用.

2)預(yù)存防積.在Docker 任務(wù)實(shí)際運(yùn)行過程中,針對(duì)計(jì)算和內(nèi)存密集型等相關(guān)變化過快的類型,為了防止頻繁地觸發(fā)預(yù)存,影響Docker 任務(wù)運(yùn)行.本文通過定時(shí)收集Docker 任務(wù)的運(yùn)行全局信息,并在一定周期之內(nèi)對(duì)全局?jǐn)?shù)據(jù)比較并分析,判斷Docker任務(wù)的變化,獲取恰當(dāng)?shù)念A(yù)存閾值參數(shù),防止預(yù)存積累,減少資源損耗.

采集云服務(wù)器節(jié)點(diǎn)的CPU、帶寬、內(nèi)存等資源的物理數(shù)據(jù)時(shí),必須保證采集的數(shù)據(jù)具有準(zhǔn)確性,同時(shí)不能對(duì)節(jié)點(diǎn)運(yùn)行的Docker 容器產(chǎn)生影響.在確定預(yù)存儲(chǔ)的判定條件之后,用戶根據(jù)任務(wù)類型設(shè)定一個(gè)預(yù)存儲(chǔ)的閾值Tpre.在一定周期T時(shí)間內(nèi),如果服務(wù)器的Pcoc值小于設(shè)定的閾值Tpre,則該物理節(jié)點(diǎn)未達(dá)到預(yù)轉(zhuǎn)儲(chǔ)觸發(fā)條件,不用考慮預(yù)存儲(chǔ)問題.除此之外,當(dāng)Pcpu＞Tpre(Pcpu),即CPU 使用率超過設(shè)定的CPU 閾值時(shí),CPU 滿足觸發(fā)條件;當(dāng)Pbw＜Tpre(Pbw),即應(yīng)用服務(wù)所需帶寬占比低于帶寬閾值時(shí),帶寬滿足觸發(fā)條件;當(dāng)Pmem＞Tpre(Pmem),即內(nèi)存使用率超過設(shè)定的內(nèi)存閾值時(shí),內(nèi)存滿足觸發(fā)條件.以上各種情況均屬于該物理節(jié)點(diǎn)滿足預(yù)存儲(chǔ)條件,在針對(duì)不同類型任務(wù)的情況下,采取不同的預(yù)設(shè)閾值.具體觸發(fā)流程的偽代碼見算法1.

算法1.預(yù)存儲(chǔ)閾值觸發(fā)判斷算法

2.2 動(dòng)態(tài)迭代遷移

綜合考慮宿主機(jī)和目的主機(jī)之間沒有共享存儲(chǔ)硬件和軟件環(huán)境,以及 D ocker 容器數(shù)據(jù)和系統(tǒng)文件的特殊性,本文設(shè)計(jì)了一種基于預(yù)存儲(chǔ)的Docker容器動(dòng)態(tài)遷移框架,采用Pre-copy 算法結(jié)合檢查點(diǎn)恢復(fù)操作的方法,以此來實(shí)現(xiàn)云端Docker 容器動(dòng)態(tài)遷移.

在Docker 容器動(dòng)態(tài)遷移時(shí),主要在兩個(gè)階段進(jìn)行容器內(nèi)部進(jìn)程運(yùn)行的相關(guān)信息傳輸: 迭代拷貝和停機(jī)拷貝階段.前者主要傳輸內(nèi)存頁面信息,首先將容器進(jìn)程所有內(nèi)存頁面?zhèn)鬏斨聊康闹鳈C(jī),再通過迭代循環(huán)實(shí)現(xiàn)臟頁的更新,當(dāng)宿主機(jī)和目的主機(jī)之間的內(nèi)存數(shù)據(jù)基本同步之后,跳轉(zhuǎn)至停機(jī)拷貝階段;后者將容器運(yùn)行剩余臟頁和狀態(tài)信息傳輸至目的主機(jī).最后在目的主機(jī)上重啟容器運(yùn)行,確保遷移的容器繼續(xù)平穩(wěn)運(yùn)行.

具體流程如圖6 所示,在宿主機(jī)、云端存儲(chǔ)和目的主機(jī)三者之間分別建立 socket 通信管道,用于數(shù)據(jù)的傳輸.數(shù)據(jù)的傳輸主要分為初始傳輸、迭代傳輸和停機(jī)傳輸.

圖6 動(dòng)態(tài)迭代遷移流程圖Fig.6 Dynamic iterative migration flowchart

1)初始傳輸.如圖6 中①所示,在遷移命令下達(dá)之后,宿主機(jī)給云端存儲(chǔ)下達(dá)遷移命令,云端存儲(chǔ)將預(yù)存儲(chǔ)數(shù)據(jù)傳輸?shù)哪康闹鳈C(jī),包括Docker 容器重啟所需的基礎(chǔ)鏡像、掛載數(shù)據(jù)和容器系統(tǒng)信息等相關(guān)數(shù)據(jù).

2)迭代傳輸.如圖中②所示,在宿主機(jī)向云端存儲(chǔ)下達(dá)遷移命令的同時(shí),宿主機(jī)對(duì)Docker 容器內(nèi)部進(jìn)程執(zhí)行檢查點(diǎn)預(yù)轉(zhuǎn)儲(chǔ)操作,然后利用Linux內(nèi)存跟蹤機(jī)制獲取修改后的內(nèi)存頁,并迭代執(zhí)行數(shù)據(jù)傳輸.最后在滿足一定的循環(huán)終止條件后,結(jié)束迭代傳輸進(jìn)入停機(jī)傳輸.

3)停機(jī)傳輸.如圖中③和④所示,對(duì)宿主機(jī)上的Docker 容器內(nèi)部進(jìn)程執(zhí)行檢查點(diǎn)轉(zhuǎn)儲(chǔ)操作,掛起容器和容器內(nèi)部運(yùn)行的程序,獲取剩余的臟頁和容器進(jìn)程執(zhí)行數(shù)據(jù)信息.將檢查點(diǎn)轉(zhuǎn)儲(chǔ)文件傳輸?shù)侥康闹鳈C(jī)上,待目的主機(jī)完全接收到重啟容器和進(jìn)程所需的文件后,執(zhí)行重啟容器操作.如若重啟成功,則動(dòng)態(tài)遷移正常結(jié)束,刪除宿主機(jī)上被掛起的Docker 容器和進(jìn)程,并卸載相關(guān)文件目錄,刪除云端存儲(chǔ)上的所有預(yù)存數(shù)據(jù)文件.反之容器與進(jìn)程回到宿主機(jī)與云端存儲(chǔ),恢復(fù)被掛起的Docker 容器與進(jìn)程.

基于預(yù)存儲(chǔ)的Docker 容器動(dòng)態(tài)遷移,物理機(jī)之間不需要共享存儲(chǔ)硬件的支持,降低了硬件環(huán)境的要求.同時(shí)Docker 容器本身開銷相對(duì)于進(jìn)程而言可以忽略不計(jì),利用Pre-copy 算法進(jìn)行迭代傳輸減少了遷移的總時(shí)間和停機(jī)時(shí)間.

3 實(shí)驗(yàn)設(shè)計(jì)與分析

3.1 實(shí)驗(yàn)設(shè)計(jì)

本節(jié)從兩個(gè)方面對(duì)PF-Docker 遷移開銷進(jìn)行評(píng)估: 應(yīng)用類型與并行度.應(yīng)用類型對(duì)在線遷移的開銷有明顯影響,本節(jié)選取了兩種代表性應(yīng)用類型,分別為內(nèi)存計(jì)算密集型和I/O 型.其次,本節(jié)還對(duì)并行程序的遷移開銷進(jìn)行了評(píng)估,主要選取了多線程Linux 內(nèi)核編譯.

本文分別從遷移總時(shí)間、宿主機(jī)遷移數(shù)據(jù)量和服務(wù)降級(jí)率3 個(gè)方面來檢測(cè)遷移效率,為此選擇了Loop 測(cè)試和Stream 測(cè)試兩種具有代表性的測(cè)試用例來檢測(cè)PF-Docker 動(dòng)態(tài)遷移的性能指標(biāo).具體如表1 所示.

表1 實(shí)驗(yàn)負(fù)載類型表Table 1 Experimental load type table

PF-Docker 框架的3 臺(tái)服務(wù)器操作系統(tǒng)均為Ubuntu14: 04.1,內(nèi)核的版本為4.2.0-36-generic,安裝相同版本CRIU 和LM-Docker,其中CRIU 為2.12,LM-Docker 是在官方Docker boucher 目錄下v1.9.0-experimental-cr.1 版本基礎(chǔ)上進(jìn)行修改.實(shí)驗(yàn)時(shí)Docker 容器中部署ubuntu 操作系統(tǒng),采用基礎(chǔ)鏡像為ubuntu14: 04.1,大小為788 MB.文獻(xiàn)[13]框架的服務(wù)器與本文的框架硬件和軟件配置一樣,不同之處在于文獻(xiàn)[13]框架采用的是兩臺(tái)服務(wù)器.

3.2 評(píng)估方法

本文采用了文獻(xiàn)[13]和[25]的評(píng)測(cè)方法,分別從遷移總時(shí)間、宿主機(jī)遷移數(shù)據(jù)量、服務(wù)降級(jí)率3個(gè)方面對(duì)PF-Docker 動(dòng)態(tài)遷移方法進(jìn)行評(píng)估.

1)遷移總時(shí)間: 是指遷移指令發(fā)起到整個(gè)遷移過程完成所耗費(fèi)的總時(shí)間,具體為

2)總遷移數(shù)據(jù)量: 是指遷移指令發(fā)起到整個(gè)遷移過程完成所傳輸數(shù)據(jù)的總量,具體為

3)服務(wù)降級(jí)率: 指動(dòng)態(tài)遷移等其他服務(wù)操作對(duì)進(jìn)程運(yùn)行的影響,具體為

3.3 實(shí)驗(yàn)結(jié)果分析

3.3.1 面向不同應(yīng)用類型的遷移

3.3.1.1 Loop 場(chǎng)景測(cè)試

在Loop 測(cè)試場(chǎng)景下對(duì)比本文和文獻(xiàn)[13]兩種Docker 遷移框架的性能.如圖7 所示,由于容器內(nèi)部應(yīng)用程序和容器自身的臟頁產(chǎn)生率較低和網(wǎng)絡(luò)傳輸?shù)难舆t性,導(dǎo)致動(dòng)態(tài)迭代遷移過程中的遷移算法和壓縮算法帶來的收益無法實(shí)現(xiàn),因此在傳輸時(shí)間開銷上,本文PF-Docker 遷移框架對(duì)比文獻(xiàn)[13]的Docker 遷移框架不占優(yōu)勢(shì).但是由于數(shù)據(jù)預(yù)存儲(chǔ)使得宿主機(jī)向目的主機(jī)傳輸?shù)臄?shù)據(jù)量降低了25%,減少了宿主機(jī)的網(wǎng)絡(luò)帶寬使用,降低了部分開銷.

圖7 讀寫空閑場(chǎng)景下兩種Docker 動(dòng)態(tài)遷移方法性能對(duì)比Fig.7 Performance comparison of two Docker dynamic migration methods in read-write idle scenarios

3.3.1.2 Stream 場(chǎng)景測(cè)試

Stream 測(cè)試是業(yè)界公認(rèn)的內(nèi)存帶寬性能測(cè)試基準(zhǔn)工具.同Loop 的讀寫空閑測(cè)試相比,Stream基準(zhǔn)測(cè)試可以選擇讀寫密集空間的測(cè)試.為了分析在不同讀寫密集空間臟頁率下PF-Docker 容器動(dòng)態(tài)遷移性能,分別選取內(nèi)存數(shù)據(jù)大小為20 MB,50 MB,100 MB,200 MB,300 MB,400 MB,500 MB,600 MB,700 MB,800 MB,900 MB,1 000 MB,1 500 MB 和2 000 MB 14 組負(fù)載進(jìn)行測(cè)試.PF-Docker 將分別從總遷移時(shí)間和總遷移數(shù)據(jù)量?jī)蓚€(gè)方向和文獻(xiàn)[13]的Docker 遷移方法進(jìn)行性能對(duì)比,從應(yīng)用程序服務(wù)降級(jí)率和KVM 動(dòng)態(tài)遷移進(jìn)行性能對(duì)比.

由于Stream 測(cè)試進(jìn)程的臟頁更新率與Stream進(jìn)程的占用內(nèi)存成正比.Docker 動(dòng)態(tài)遷移面臨著隨內(nèi)存占用的增大,Stream 測(cè)試進(jìn)程的臟頁更新率不斷增大以及網(wǎng)絡(luò)帶寬的堵塞,導(dǎo)致動(dòng)態(tài)遷移長(zhǎng)時(shí)間內(nèi)無法實(shí)現(xiàn)數(shù)據(jù)的收斂,增加了動(dòng)態(tài)遷移針對(duì)臟頁傳輸?shù)牡螖?shù),從而導(dǎo)致整個(gè)動(dòng)態(tài)遷移的總時(shí)間會(huì)不斷增加.而在本文PF-Docker 遷移框架中,由于提前將數(shù)據(jù)預(yù)存儲(chǔ),減少了預(yù)傳輸階段對(duì)源主機(jī)網(wǎng)絡(luò)帶寬的堵塞,使得動(dòng)態(tài)遷移算法可以更快地實(shí)現(xiàn)數(shù)據(jù)的收斂.

圖8 為PF-Docker 遷移框架和文獻(xiàn)[13] 的Docker 遷移框架在遷移總時(shí)間開銷方面的對(duì)比,分析發(fā)現(xiàn)當(dāng)Stream 的內(nèi)存占用在500 MB 之前時(shí),對(duì)比兩種框架在總遷移時(shí)間并沒有很大的變化,然而在500 MB 之后,隨著Stream 內(nèi)存占用的不斷增大,網(wǎng)絡(luò)帶寬堵塞的情況越來越嚴(yán)重,導(dǎo)致容器動(dòng)態(tài)遷移的數(shù)據(jù)收斂越來越困難,而本文PF-Docker遷移框架在遷移總時(shí)間開銷的效果就越來越明顯,總遷移時(shí)間相比于文獻(xiàn)[13]的方法降低了20%.

圖8 遷移總時(shí)間對(duì)比Fig.8 The comparison of total migration time

圖9 為PF-Docker 遷移框架數(shù)據(jù)總傳輸量和Docker 遷移框架數(shù)據(jù)總傳輸量.其中,根據(jù)PFDocker 遷移框架的特殊性,為更好地分析數(shù)據(jù)傳輸來源,將其又細(xì)分為宿主機(jī)傳輸數(shù)據(jù)量和預(yù)存儲(chǔ)傳輸數(shù)據(jù)量.實(shí)驗(yàn)對(duì)比中,PF-Docker 的數(shù)據(jù)總傳輸量始終低于Docker 動(dòng)態(tài)遷移框架,并隨著Stream內(nèi)存占比的不斷增加,數(shù)據(jù)總傳輸量的優(yōu)勢(shì)越來越明顯.同時(shí)根據(jù)對(duì)PF-Docker 的數(shù)據(jù)來源分析,分為預(yù)存儲(chǔ)和宿主機(jī)分別向目的主機(jī)傳輸,而Docker遷移框架只采用宿主機(jī)向目的主機(jī)的傳輸方式,對(duì)比分析發(fā)現(xiàn)在單一從宿主機(jī)向目的主機(jī)傳輸?shù)臄?shù)據(jù)量中,PF-Docker 的宿主機(jī)傳輸量低于Docker 遷移框架的宿主機(jī)傳輸量,隨著數(shù)據(jù)的收斂和迭代傳輸次數(shù)的減少,在宿主機(jī)總遷移數(shù)據(jù)也降低了22%.

如圖10 所示,實(shí)驗(yàn)測(cè)試內(nèi)容包括Docker、PFDocker、KVM 和LM-KVM,分別代表Docker 本地執(zhí)行、PF-Docker 動(dòng)態(tài)遷移、KVM 本地執(zhí)行和KVM 動(dòng)態(tài)遷移.通過實(shí)驗(yàn)對(duì)比Docker、PF-Docker、KVM 和LM-KVM 在Stream 執(zhí)行時(shí)間隨臟頁速率的變化.可以看到,PF-Docker 動(dòng)態(tài)遷移在臟頁率較少時(shí),性能略差于KVM 本地執(zhí)行,但隨著臟頁率增加,PF-Docker 方法表現(xiàn)越好.從圖10 中還可以看出,在該實(shí)驗(yàn)場(chǎng)景下,Docker 和KVM 性能差異不是很大,這是由于Stream 測(cè)試中內(nèi)存讀寫操作是連續(xù)的,內(nèi)核通過數(shù)據(jù)預(yù)取操作進(jìn)行優(yōu)化,KVM 虛擬內(nèi)存和宿主機(jī)物理內(nèi)存映射次數(shù)較少.這也是本文選擇Stream 測(cè)試工具作為對(duì)比分析動(dòng)態(tài)遷移性能差異的原因.

圖10 Stream 測(cè)試下PF-Docker 與LM-KVM 對(duì)比Fig.10 The comparison of PF-Docker and LM-KVM under Stream test

3.3.2 面向并行程序的遷移

以下對(duì)內(nèi)核編譯測(cè)試數(shù)據(jù)進(jìn)行分析.如圖11所示,對(duì)比Docker 本地執(zhí)行和KVM 本地執(zhí)行性能,在8,4,2,1 四種多線程并發(fā)下本地KVM 開銷比Docker 分別多耗了33.3%,38.1%,17.9%,18.5%.PF-Docker 動(dòng)態(tài)遷移執(zhí)行性能相比Docker 本地分別下降了4.8%,3.6%,2.4%,1.8%.KVM動(dòng)態(tài)遷移執(zhí)行性能相比KVM 本地分別下降了21.4%,17.2%,183%,78%.KVM 動(dòng)態(tài)遷移執(zhí)行開銷相比PF-Docker 動(dòng)態(tài)遷移分別多耗了54.6%,56.3%,225%,107%.由此可知,在多線程并發(fā)高負(fù)載下PF-Docker 動(dòng)態(tài)遷移帶來的服務(wù)降級(jí)率比KVM要低.

圖11 內(nèi)核編譯負(fù)載下Docker 與KVM 對(duì)比Fig.11 The comparison of Docker and KVM under the kernel compilation load

3.3.3 面向風(fēng)險(xiǎn)遷移過程

針對(duì)計(jì)算密集型和內(nèi)存密集型的進(jìn)程,在遷移過程出現(xiàn)失敗的幾率會(huì)大大增加,結(jié)合在第 2 節(jié)提到的3 個(gè)預(yù)存條件(CPU、內(nèi)存、帶寬)和執(zhí)行多線程編譯任務(wù)的實(shí)驗(yàn)數(shù)據(jù)進(jìn)行動(dòng)態(tài)遷移的風(fēng)險(xiǎn)遷移分析.

如圖12 所示,預(yù)存階段頻繁使用3 個(gè)單一的閾值觸發(fā)判定條件會(huì)一定程度影響計(jì)算密集型和內(nèi)存密集型任務(wù)的運(yùn)行狀態(tài),本文通過預(yù)存閾值的動(dòng)態(tài)調(diào)控機(jī)制,同等環(huán)境下對(duì)比任務(wù)自身運(yùn)行狀態(tài)升高了7%,但對(duì)比單一閾值判定條件對(duì)任務(wù)運(yùn)行狀態(tài)的影響降低了5%,采用預(yù)存閾值動(dòng)態(tài)調(diào)控機(jī)制,能一定程度降低對(duì)任務(wù)本身運(yùn)行狀態(tài)的影響.

圖12 多線程內(nèi)核編譯在不同預(yù)存條件下對(duì)比Fig.12 The comparison of multithreaded kernel compilation under different pre-stored conditions

總的來說,本文提出的基于Docker 容器動(dòng)態(tài)遷移預(yù)存儲(chǔ)算法是在整個(gè)遷移過程中分別加入第三方數(shù)據(jù)管理平臺(tái)、引入預(yù)存儲(chǔ)閾值機(jī)制.實(shí)驗(yàn)對(duì)比表明,從總傳輸數(shù)據(jù)量、總遷移時(shí)間、服務(wù)降級(jí)率三個(gè)方面來看,在Loop 測(cè)試和Stream 測(cè)試上,本文框架比文獻(xiàn)[13]中的框架從以下幾個(gè)方面都有所降低,其中包括數(shù)據(jù)量、傳輸時(shí)間等,在Stream 測(cè)試和內(nèi)核編譯測(cè)試上,本文Docker 遷移框架比KVM 動(dòng)態(tài)遷移服務(wù)性能更加優(yōu)秀和穩(wěn)定.從而進(jìn)一步提高了云中資源的利用率,降低了部分服務(wù)器的高負(fù)載問題.

4 結(jié)束語

隨著云計(jì)算技術(shù)的高速發(fā)展,如何降低能耗是保證高效利用云資源的前提.Docker 作為目前業(yè)界使用率最高的容器引擎,實(shí)現(xiàn)其動(dòng)態(tài)遷移技術(shù)能有效降低能耗,提高容器本身的容錯(cuò)率.實(shí)驗(yàn)結(jié)果表明,本文提出的基于Docker 容器動(dòng)態(tài)遷移預(yù)存儲(chǔ)算法通過在容器遷移過程加入預(yù)存儲(chǔ)機(jī)制和引入預(yù)存儲(chǔ)閾值的操作,使得容器遷移過程中減少了不必要的遷移,從而提高了遷移的效率和降低了能耗,可以幫助現(xiàn)有的云資源進(jìn)行有效的利用和管理.隨著容器遷移技術(shù)的持續(xù)發(fā)展,在后續(xù)研究中,將會(huì)進(jìn)一步考慮降低內(nèi)存頁的傳輸量和數(shù)據(jù)的存儲(chǔ)開銷,研究并設(shè)計(jì)切實(shí)可行的相關(guān)算法,最后從大規(guī)模任務(wù)、跨域云遷移等多種環(huán)境來證實(shí)算法的可行性,使得容器遷移更加有效、節(jié)能.