基于云預存儲技術的Docker 在線遷移方法

趙 旭 李艷梅 羅 建 羅金梅

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

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

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

圖1 2018 年RightScale 云計算調查報告Fig.1 RightScale cloud survey report of 2018

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

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

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

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

本文主要貢獻如下:

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

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

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

1 相關工作研究

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

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

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

2 PF-Docker 基于預存儲的動態遷移方法

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

2.1 動態云預存

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

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

為了描述這一問題,本文對預存數據進行如下定義: 宿主機容器和內部進程數據單次修改頻率為C,那么n次數據修改頻率為η=當迭代傳輸次數小于數據修改率η時,滿足預存數據的定義,進行有效的預存傳輸.

遷移總數據包含預存數據和宿主機數據,而預存數據量與宿主機數據量成反比,預存數據量越多,則留在宿主機的數據量越少,網絡傳輸和云存儲的利用率也就越高.如圖5 所示,預存數據分為Docker容器環境依賴和進程的數據文件,其中Docker 容器環境依賴包括基礎鏡像、子系統文件和掛載數據,進程的數據文件包括應用的內存頁、程序輸出數據和進程執行信息.分析發現Docker 容器的環境依賴文件基本不會發生變化,可以直接傳給云端存儲器;而進程的數據文件會隨著程序的運行發生改變,這時需要采用動態預存算法對該部分數據文件進行分類處理,尋找出符合條件的預存數據,再傳給云端存儲器.具體的預存傳輸過程分為以下兩部分:

圖5 動態云預存傳輸流程圖Fig.5 Dynamic cloud pre-storage transfer flowchart

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

2)利用Docker 本身提供的inspect 接口實現相關函數的調用,獲取與容器相關的數據信息,將Docker 容器運行所需的基礎鏡像、掛載數據、子系統文件和其他穩定的數據信息預存儲到云端存儲平臺,等待容器動態遷移命令下達.

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

宿主機的CPU 使用率為

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

宿主機的帶寬使用率為

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

宿主機的內存使用率為

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

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

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

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

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

算法1.預存儲閾值觸發判斷算法

2.2 動態迭代遷移

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

在Docker 容器動態遷移時,主要在兩個階段進行容器內部進程運行的相關信息傳輸: 迭代拷貝和停機拷貝階段.前者主要傳輸內存頁面信息,首先將容器進程所有內存頁面傳輸至目的主機,再通過迭代循環實現臟頁的更新,當宿主機和目的主機之間的內存數據基本同步之后,跳轉至停機拷貝階段;后者將容器運行剩余臟頁和狀態信息傳輸至目的主機.最后在目的主機上重啟容器運行,確保遷移的容器繼續平穩運行.

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

圖6 動態迭代遷移流程圖Fig.6 Dynamic iterative migration flowchart

1)初始傳輸.如圖6 中①所示,在遷移命令下達之后,宿主機給云端存儲下達遷移命令,云端存儲將預存儲數據傳輸的目的主機,包括Docker 容器重啟所需的基礎鏡像、掛載數據和容器系統信息等相關數據.

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

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

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

3 實驗設計與分析

3.1 實驗設計

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

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

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

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

3.2 評估方法

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

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

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

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

3.3 實驗結果分析

3.3.1 面向不同應用類型的遷移

3.3.1.1 Loop 場景測試

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

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

3.3.1.2 Stream 場景測試

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

由于Stream 測試進程的臟頁更新率與Stream進程的占用內存成正比.Docker 動態遷移面臨著隨內存占用的增大,Stream 測試進程的臟頁更新率不斷增大以及網絡帶寬的堵塞,導致動態遷移長時間內無法實現數據的收斂,增加了動態遷移針對臟頁傳輸的迭代次數,從而導致整個動態遷移的總時間會不斷增加.而在本文PF-Docker 遷移框架中,由于提前將數據預存儲,減少了預傳輸階段對源主機網絡帶寬的堵塞,使得動態遷移算法可以更快地實現數據的收斂.

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

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

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

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

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

3.3.2 面向并行程序的遷移

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

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

3.3.3 面向風險遷移過程

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

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

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

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

4 結束語

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