移動邊緣計算環境下容器實時遷移方法

羅 藝，江凌云

（南京郵電大學，江蘇 南京 210003）

0 引言

作為計算范式的下一次演進，移動邊緣計算（Mobile Edge Computing，MEC）使計算、存儲和通信更接近最終用戶[1,2]。與云計算相比，它允許移動用戶將其計算密集型任務，如圖像處理，卸載到附近的邊緣服務器，以顯著減少端到端（End-to-End，E2E）延遲。邊緣計算的主要挑戰之一是保證服務質量優于傳統云服務，同時將服務卸載到離最終用戶最近的邊緣服務器上[3]。然而，當最終用戶離開附近的邊緣服務器時，由于網絡連接的惡化，服務質量將顯著下降。理想情況下，當最終用戶移動時，邊緣服務器上的服務也應該實時遷移到附近的新服務器上，以響應用戶的移動性，確保最短的延遲和最佳的邊緣服務供應。

服務遷移可以分為有狀態遷移和無狀態遷移。無狀態遷移不移動應用程序的運行狀態，只是將用戶的請求重定向到一個新的服務器上，并有一個單獨的服務實例在運行，這適用于不為用戶保留狀態的應用。然而，對于當今越來越流行的交互式服務，如主動安全預警、移動多媒體和移動在線游戲等應用，很可能需要為每個用戶保留一些狀態。因此，本文中重點討論有狀態的遷移，它涉及移動應用程序的運行狀態，在這種情況下，用戶連續一段時間接受服務，服務應用可能需要為用戶保留一些內部狀態，如一些中間數據處理結果。遷移完成后，程序完全恢復到遷移前的狀態，因此遷移被歸為實時的。但是服務遷移也有副作用，它可能會導致性能下降，甚至在遷移期間中斷正在進行的服務。因此，高效完整地實時遷移對于在邊緣計算環境中實現邊緣服務的移動性至關重要[4]。

虛擬化是云計算和邊緣計算的一個重要方面。將云服務或邊緣服務作為虛擬環境，如虛擬機、容器，可提供極大的彈性和隔離性，從而允許多租戶提高資源利用效率。一個邊緣服務器承載多個虛擬環境或卸載的服務，每個虛擬環境運行一個用戶卸載的任務，對封裝在虛擬機或容器中的服務進行節點間遷移，這種方式具有高度靈活性和適應性。與傳統的虛擬機（Virtual Machine，VM）創建完整的客戶操作系統不同[5]，容器技術是一種輕量級虛擬化技術，它共享相同的操作系統內核并將應用程序進程與系統的其余部分隔離開來。因此，容器不僅解決了環境依賴問題，而且顯著減少了內存占用、初始化和遷移開銷[6]。本文利用容器特性，將容器分為基礎層和數據層，對于基礎層，只遷移目標節點缺失的那些層，以減少數據傳輸量；對于數據層遷移，采用預轉儲的方法，在服務遷移開始之前，迭狀轉儲包括內存數據和執行狀態等信息到目標節點上，在服務遷移觸發后，此時只用傳輸一小部分改變的狀態信息，大大減少了服務的停機時間，提高了服務質量。

本文的第1節介紹近年來有關虛擬化環境下容器的服務遷移方法的相關研究；第2節介紹Docker的分層架構和基于檢查點/恢復技術（Checkpoint/Restore In Userspace，CRIU）的容器預轉儲遷移方法的詳細過程；第3節評估所提方法的性能；第4節對論文進行總結，并在當前的工作基礎上做進一步的展望。

1 相關工作

虛擬化環境下進行容器遷移并保證服務質量一直是一個熱門話題，引起了許多學者的關注。文獻[7]和文獻[8]研究了云計算中心場景下的服務遷移，然而邊緣網絡中的服務遷移受到一些在云環境中不存在的影響，例如，相比于云中心環境，邊緣網絡的吞吐量更低，要求遷移過程中傳輸的數據量越少越好。文獻[9]提出了一個在數據中心環境中實時遷移Linux容器（Linux Container，LXC）的基本解決方案。然而，LXC將容器視為整個系統的容器，沒有分層存儲。因此，在容器遷移過程中，該容器的文件系統的所有內容必須一起遷移，同時還包括所有的內存狀態。文獻[10]提出了基于遠程同步（rsync）增量功能的、支持分層的容器的實時遷移；然而，由于它只支持預定義的整個系統的2或3層，在容器運行時同步文件系統有可能遇到rsync文件爭奪問題，此外文獻[10]中基礎層的重復復制可能會產生更多的性能開銷。文獻[11]支持容器的有狀態遷移，并將CRIU的內存遷移與聯合掛載的數據聯合功能相結合，以最大限度地減少遷移停機時間，然后通過源主機和目標主機之間的數據聯合視圖，容器可以在目標主機上立即恢復運行；然而，僅通過在節點之間同步根文件系統來遷移圖像，沒有考慮底層的分層存儲，這使得遷移在網絡邊緣的速度較低。文獻[12]在實時遷移過程中保證了邊緣服務器場景下Docker容器的組件完整性；但由于從中央鏡像注冊中心提取鏡像進行鏡像遷移，消耗了鏡像注冊中心的巨大帶寬，導致可擴展性差和無法容忍的停機時間，影響了遷移性能。

綜上所述，以上提出的關于容器遷移的解決方法，對于Docker容器的分層存儲特性沒有加以利用，并且對于容器的基礎層和數據層遷移方法沒有一個統一完整的解決方案；因此，本文設計一個通用的容器遷移框架，根據實際情況選擇不同粒度的服務遷移，減少不必要的信息傳輸，以最小化服務的停機時間和總遷移時間。

2 容器遷移方案

本節首先給出Docker容器的架構，其次給出基于容器分層存儲架構和CRIU的遷移機制。

2.1 Docker架構

Docker容器的架構和層級架構分別如圖1、圖2所示，Docker使用客戶端—服務器架構，用戶借助Docker客戶端與Docker daemon完成對話，Docker daemon負責編排容器、鏡像管理、執行邏輯、提供REST API等重要功能。1個Docker容器是在1個Docker鏡像之上創建的，鏡像有多層存儲，每個Docker鏡像都引用了一個代表文件系統差異的只讀層列表[13]。當1個新的容器被創建時，1個可讀可寫的存儲層被創建在鏡像層的堆棧之上，上面的新層被稱為容器層。對容器所做的所有改變，例如創建、修改或刪除任何文件都會寫入這個容器層。

圖2 Docker層級架構

2.2 遷移機制

圖3詳細介紹一個實時遷移的流程。本文把提出的解決方案分為磁盤遷移階段和內存遷移階段兩個主要部分。最初，遷移行動的需求是由管理平面檢測出來的，它可以是ETSI網絡功能虛擬化（ETSINetwork Functions Virtualization，ETSI-NFV）的架構的一部分[14]。本文假設用戶移動性可以預測，在遷移目標服務器已知的情況下使用遷移方法完成遷移。

內存遷移檢查（圖3中的步驟1）是最初的測試，在這里，克隆鏡像（基本鏡像和應用程序）在目標MEC主機中的可用性得到了驗證。如果可用，就開始克隆過程，然后進行內存遷移。

部分遷移檢查（圖3中的步驟2）是在克隆鏡像不可用的情況下進行的。在目標MEC進行驗證，以找到基本鏡像，例如，在Ubuntu的情況下，Trusty一旦找到，就開始克隆基本鏡像，然后將應用數據從源MEC復制到目標MEC并進行內存遷移。

完整的遷移檢查（圖3中的步驟3）代表了最后一步和最壞的情況，因為它們在目標MEC中不存在，需要將整個文件系統（rootfs）、應用程序和內存轉移到目標MEC。

圖3 遷移機制流程

以上3個步驟針對目標MEC容器的磁盤進行遷移，磁盤遷移針對的遷移對象是持久性數據，在完成遷移后，緊接著遷移內存數據。在邊緣計算的環境下運行的服務，經常碰到執行瞬時數據分析和時間關鍵控制這類情況，那么針對這些非持久性數據，如何快速遷移到目標MEC上也是一個很重要的問題。因此，本文提出了一種基于CRIU的預轉儲實時遷移方法。CRIU工具將被用來反復轉儲容器的內存，當它在運行時，轉儲到源MEC主機的一個tmpfs掛載的目錄；然后，每個轉儲都會通過網絡復制到目標主機的tmpfs-mounted目錄中；最后，容器將在目標MEC主機上被恢復。之所以稱為預轉儲遷移，是因為它在凍結容器之前反復轉儲容器的內存到源MEC主機的一個tmpfs掛載的目錄，接著，每個轉儲都會通過網絡復制到目標主機的tmpfs-mounted目錄中，然后進行最終的轉儲和狀態傳輸，最后容器在目標節點上恢復運行。在預轉儲階段執行多次迭代遷移，每次迭代只轉儲和重新傳輸在前一次迭代期間修改的那些內存頁面（第一次迭代轉儲和傳輸整個容器狀態）。圖4描述了迭代遷移的詳細步驟，修改后的內存頁稱為臟頁。

圖4 內存迭代遷移

此實現基于CRIU，它提供了必要的基本機制（例如，-pre-dump 選項）來預轉儲容器的運行時狀態并在之后恢復它。預轉儲遷移的停機時間受傳輸臟頁數量的影響，預轉儲迭代遷移產生的臟頁數量會受到兩個因素的影響：首先是容器托管服務的頁面變臟率，即服務修改內存頁面的速度；其次是預轉儲階段傳輸的數據量，因為該階段傳輸的數據越多，服務修改頁面的時間就越多。值得注意的是，這兩個因素應該始終對照源節點和目標節點之間的可用帶寬來考慮。當然，迭代遷移并不是無休止地迭代，通常，預轉儲階段的迭代是收斂的，即持續時間越來越短。如果迭代，預轉儲階段通常在達到預定迭代次數時或者臟頁閾值時結束。因此需要定義一個明確的內存頁數，以保證最短的停機時間，或者使用一個固定的迭代次數，以避免無限循環，即頁面數量永遠不會低于預先定義的臟頁閾值。當連續迭代中的增量內存檢查點文件的大小低于閾值時，應該開始停止并復制。在此方案中，判斷迭代過程是否發散的依據是本次迭代中增量內存的大小是否大于上一次迭代。

3 結果評估

3.1 實驗設置

本節評估所提出的容器遷移解決方案。使用虛擬化節點，宿主虛擬機分別從一臺物理機上獲得2 GB虛擬內存和2個虛擬中央處理器（Central Processing Unit，CPU）核，物理機配置有2.6 GHz的英特爾酷睿i7和16 GB內存。兩個虛擬機運行Ubuntu 16.04 LTS和Linux 4.15.0通用內核，并作為MEC在其間進行遷移，CRIU版本是3.16，docker版本是20.10。實驗使用Linux tc實用程序設置虛擬節點間不同帶寬（帶寬分別設置為10 Mbit/s和100 Mbit/s），模擬擁塞和理想的網絡條件。容器運行時大小設置為100 MB，本文考慮的是已經安裝在目標節點上的服務，因此遷移對象是容器的數據層。考慮臟頁變化率對實驗結果的影響，在移動性場景下，邊緣設備會頻繁地請求數據更新，這對于內存來說消耗巨大[15]，設置兩種臟頁變化率（分別為10 KB/s和300 KB/s）模擬方案對于臟頁變化率的敏感度。

遷移容器所花費的總時間主要由以下幾部分 組成：

（1）預轉儲階段將生成的預轉儲數據從源節點傳輸到目標節點的時間；

（2）在轉儲階段將生成的轉儲數據從源節點傳輸到目標節點的時間；

（3）遷移到目標節點后容器恢復的時間。

服務的停機時間主要由傳輸轉儲數據導致。

3.2 結果分析

本文通過實驗評估所提方案的性能，并與傳統的冷遷移進行了對比，對比實驗分別在不同臟頁變化率和不同帶寬的條件下進行，對比結果如表1、表2所示。冷遷移的步驟主要分為3步：首先凍結/停止容器以確保它不在修改狀態，其次在容器停止時轉儲整個狀態并轉移它，最后當所有狀態都可用時，在目的地恢復容器。

表1 臟頁變化率為10 KB/s時的性能對比

表2 臟頁變化率為300 KB/s時的性能對比

從總遷移時間角度分析，無論何種網絡情況、何種臟頁變化率，冷遷移的總遷移時間最長，因為該方法沒有考慮容器的分層存儲特性，每次進行服務遷移時，遷移整個容器到目標節點，傳輸的數據量遠遠超過所提方案。但是，當臟頁變化率提高一個量級之后，所提方案的總遷移時間在網絡條件較差的環境下與冷遷移接近，這是因為冷遷移在遷移過程中不考慮內存頁變化，它總是將容器整體打包傳輸給目標節點，所有的內存頁只傳輸一次。而所提方案考慮將內存頁迭代遷移，在臟頁變化率增大的情況下，預轉儲階段被弄臟的頁面數量與該階段轉移的頁面數量相當，導致內存頁傳輸了不止一次，預轉儲遷移的數據轉儲量相當大。在網絡條件理想的情況下，雖然臟頁變化率增大，但是遠不及網絡吞吐量，所以轉儲階段遷移不受影響。

從停機時間角度考慮，無論何種網絡情況、何種臟頁變化率，冷遷移的停機時間最長，幾乎與其總遷移時間吻合。這是因為冷遷移和預轉儲遷移之間的主要區別在于其轉儲的性質，冷遷移中的轉儲代表整個容器狀態，因此始終包括所有內存頁面和執行狀態。相反，預轉儲遷移中的轉儲僅包括在預轉儲階段修改的那些內存頁面，以及執行狀態的更改；因此，預轉儲遷移的停機時間比冷遷移的停機時間短。但是冷遷移的遷移性能不受臟頁變化率的約束，在同樣的網絡條件下停機時間幾乎一致。而所提方案在網絡條件較差、臟頁變化率變高的條件下，停機時間增加明顯，性能下降，原因在于此情況下臟頁變化率數量級更接近帶寬，導致最終轉儲的臟頁數量增多。但是當所提方案在網絡條件理想的情況下，停機時間不受臟頁變化率的影響，這是因為在這些條件下，很少有內存頁在預轉儲階段被修改，所提方案在轉儲階段傳輸的數據量幾乎一致。

4 結語

容器化和容器遷移是邊緣計算的一個基本方面，移動邊緣計算是一種范式，在網絡邊緣附近提供計算、存儲和網絡的資源及服務。本文批判性地分析了現有的容器遷移技術，并特別關注它們對邊緣計算環境的適用性，結合現有的遷移技術和工具，提出了基于容器分層特性的預轉儲遷移方案，該方案利用容器的鏡像層與容器層分離的特性，在遷移過程根據目標節點的實際情況，只傳輸缺失的鏡像層，以此減少網絡負擔。在考慮到遷移過程的停機時間時，本文采用預轉儲方法，在遷移開始前迭代遷移內存頁，以此減少轉儲過程中傳輸的狀態信息，降低服務遷移停機時間。最后在實驗平臺上對該方案進行了全面的性能評估，觀察它在不同的網絡條件和頁面變臟率條件下的遷移性能。在評估了總遷移時間、停機時間后，結果表明所提方案表現優異，在網絡條件理想的情況下，停機時間接近1 s。

在未來工作中，將繼續探索容器的服務遷移方法，利用人工智能的手段來決定和執行服務遷移的觸發時間，以提高方法的性能。