基于云預(yù)存儲技術(shù)的Docker 在線遷移方法

趙 旭 李艷梅 羅 建 羅金梅

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

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

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

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

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

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

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

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

本文主要貢獻如下:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

宿主機的CPU 使用率為

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

宿主機的帶寬使用率為

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 實驗設(shè)計與分析

3.1 實驗設(shè)計

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

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

表1 實驗負載類型表Table 1 Experimental load type table

PF-Docker 框架的3 臺服務(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ǔ)上進行修改.實驗時Docker 容器中部署ubuntu 操作系統(tǒng),采用基礎(chǔ)鏡像為ubuntu14: 04.1,大小為788 MB.文獻[13]框架的服務(wù)器與本文的框架硬件和軟件配置一樣,不同之處在于文獻[13]框架采用的是兩臺服務(wù)器.

3.2 評估方法

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

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

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

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

3.3 實驗結(jié)果分析

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

3.3.1.1 Loop 場景測試

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

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

3.3.1.2 Stream 場景測試

Stream 測試是業(yè)界公認的內(nèi)存帶寬性能測試基準工具.同Loop 的讀寫空閑測試相比,Stream基準測試可以選擇讀寫密集空間的測試.為了分析在不同讀寫密集空間臟頁率下PF-Docker 容器動態(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 組負載進行測試.PF-Docker 將分別從總遷移時間和總遷移數(shù)據(jù)量兩個方向和文獻[13]的Docker 遷移方法進行性能對比,從應(yīng)用程序服務(wù)降級率和KVM 動態(tài)遷移進行性能對比.

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

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

圖8 遷移總時間對比Fig.8 The comparison of total migration time

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

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

圖10 Stream 測試下PF-Docker 與LM-KVM 對比Fig.10 The comparison of PF-Docker and LM-KVM under Stream test

3.3.2 面向并行程序的遷移

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

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

3.3.3 面向風險遷移過程

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

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

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

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

4 結(jié)束語

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