移動(dòng)邊緣計(jì)算環(huán)境下容器實(shí)時(shí)遷移方法

羅 藝，江凌云

（南京郵電大學(xué)，江蘇 南京 210003）

0 引言

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

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

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

本文的第1節(jié)介紹近年來(lái)有關(guān)虛擬化環(huán)境下容器的服務(wù)遷移方法的相關(guān)研究；第2節(jié)介紹Docker的分層架構(gòu)和基于檢查點(diǎn)/恢復(fù)技術(shù)（Checkpoint/Restore In Userspace，CRIU）的容器預(yù)轉(zhuǎn)儲(chǔ)遷移方法的詳細(xì)過(guò)程；第3節(jié)評(píng)估所提方法的性能；第4節(jié)對(duì)論文進(jìn)行總結(jié)，并在當(dāng)前的工作基礎(chǔ)上做進(jìn)一步的展望。

1 相關(guān)工作

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

綜上所述，以上提出的關(guān)于容器遷移的解決方法，對(duì)于Docker容器的分層存儲(chǔ)特性沒(méi)有加以利用，并且對(duì)于容器的基礎(chǔ)層和數(shù)據(jù)層遷移方法沒(méi)有一個(gè)統(tǒng)一完整的解決方案；因此，本文設(shè)計(jì)一個(gè)通用的容器遷移框架，根據(jù)實(shí)際情況選擇不同粒度的服務(wù)遷移，減少不必要的信息傳輸，以最小化服務(wù)的停機(jī)時(shí)間和總遷移時(shí)間。

2 容器遷移方案

本節(jié)首先給出Docker容器的架構(gòu)，其次給出基于容器分層存儲(chǔ)架構(gòu)和CRIU的遷移機(jī)制。

2.1 Docker架構(gòu)

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

圖2 Docker層級(jí)架構(gòu)

2.2 遷移機(jī)制

圖3詳細(xì)介紹一個(gè)實(shí)時(shí)遷移的流程。本文把提出的解決方案分為磁盤遷移階段和內(nèi)存遷移階段兩個(gè)主要部分。最初，遷移行動(dòng)的需求是由管理平面檢測(cè)出來(lái)的，它可以是ETSI網(wǎng)絡(luò)功能虛擬化（ETSINetwork Functions Virtualization，ETSI-NFV）的架構(gòu)的一部分[14]。本文假設(shè)用戶移動(dòng)性可以預(yù)測(cè)，在遷移目標(biāo)服務(wù)器已知的情況下使用遷移方法完成遷移。

內(nèi)存遷移檢查（圖3中的步驟1）是最初的測(cè)試，在這里，克隆鏡像（基本鏡像和應(yīng)用程序）在目標(biāo)MEC主機(jī)中的可用性得到了驗(yàn)證。如果可用，就開(kāi)始克隆過(guò)程，然后進(jìn)行內(nèi)存遷移。

部分遷移檢查（圖3中的步驟2）是在克隆鏡像不可用的情況下進(jìn)行的。在目標(biāo)MEC進(jìn)行驗(yàn)證，以找到基本鏡像，例如，在Ubuntu的情況下，Trusty一旦找到，就開(kāi)始克隆基本鏡像，然后將應(yīng)用數(shù)據(jù)從源MEC復(fù)制到目標(biāo)MEC并進(jìn)行內(nèi)存遷移。

完整的遷移檢查（圖3中的步驟3）代表了最后一步和最壞的情況，因?yàn)樗鼈冊(cè)谀繕?biāo)MEC中不存在，需要將整個(gè)文件系統(tǒng)（rootfs）、應(yīng)用程序和內(nèi)存轉(zhuǎn)移到目標(biāo)MEC。

圖3 遷移機(jī)制流程

以上3個(gè)步驟針對(duì)目標(biāo)MEC容器的磁盤進(jìn)行遷移，磁盤遷移針對(duì)的遷移對(duì)象是持久性數(shù)據(jù)，在完成遷移后，緊接著遷移內(nèi)存數(shù)據(jù)。在邊緣計(jì)算的環(huán)境下運(yùn)行的服務(wù)，經(jīng)常碰到執(zhí)行瞬時(shí)數(shù)據(jù)分析和時(shí)間關(guān)鍵控制這類情況，那么針對(duì)這些非持久性數(shù)據(jù)，如何快速遷移到目標(biāo)MEC上也是一個(gè)很重要的問(wèn)題。因此，本文提出了一種基于CRIU的預(yù)轉(zhuǎn)儲(chǔ)實(shí)時(shí)遷移方法。CRIU工具將被用來(lái)反復(fù)轉(zhuǎn)儲(chǔ)容器的內(nèi)存，當(dāng)它在運(yùn)行時(shí)，轉(zhuǎn)儲(chǔ)到源MEC主機(jī)的一個(gè)tmpfs掛載的目錄；然后，每個(gè)轉(zhuǎn)儲(chǔ)都會(huì)通過(guò)網(wǎng)絡(luò)復(fù)制到目標(biāo)主機(jī)的tmpfs-mounted目錄中；最后，容器將在目標(biāo)MEC主機(jī)上被恢復(fù)。之所以稱為預(yù)轉(zhuǎn)儲(chǔ)遷移，是因?yàn)樗趦鼋Y(jié)容器之前反復(fù)轉(zhuǎn)儲(chǔ)容器的內(nèi)存到源MEC主機(jī)的一個(gè)tmpfs掛載的目錄，接著，每個(gè)轉(zhuǎn)儲(chǔ)都會(huì)通過(guò)網(wǎng)絡(luò)復(fù)制到目標(biāo)主機(jī)的tmpfs-mounted目錄中，然后進(jìn)行最終的轉(zhuǎn)儲(chǔ)和狀態(tài)傳輸，最后容器在目標(biāo)節(jié)點(diǎn)上恢復(fù)運(yùn)行。在預(yù)轉(zhuǎn)儲(chǔ)階段執(zhí)行多次迭代遷移，每次迭代只轉(zhuǎn)儲(chǔ)和重新傳輸在前一次迭代期間修改的那些內(nèi)存頁(yè)面（第一次迭代轉(zhuǎn)儲(chǔ)和傳輸整個(gè)容器狀態(tài)）。圖4描述了迭代遷移的詳細(xì)步驟，修改后的內(nèi)存頁(yè)稱為臟頁(yè)。

圖4 內(nèi)存迭代遷移

此實(shí)現(xiàn)基于CRIU，它提供了必要的基本機(jī)制（例如，-pre-dump 選項(xiàng)）來(lái)預(yù)轉(zhuǎn)儲(chǔ)容器的運(yùn)行時(shí)狀態(tài)并在之后恢復(fù)它。預(yù)轉(zhuǎn)儲(chǔ)遷移的停機(jī)時(shí)間受傳輸臟頁(yè)數(shù)量的影響，預(yù)轉(zhuǎn)儲(chǔ)迭代遷移產(chǎn)生的臟頁(yè)數(shù)量會(huì)受到兩個(gè)因素的影響：首先是容器托管服務(wù)的頁(yè)面變臟率，即服務(wù)修改內(nèi)存頁(yè)面的速度；其次是預(yù)轉(zhuǎn)儲(chǔ)階段傳輸?shù)臄?shù)據(jù)量，因?yàn)樵撾A段傳輸?shù)臄?shù)據(jù)越多，服務(wù)修改頁(yè)面的時(shí)間就越多。值得注意的是，這兩個(gè)因素應(yīng)該始終對(duì)照源節(jié)點(diǎn)和目標(biāo)節(jié)點(diǎn)之間的可用帶寬來(lái)考慮。當(dāng)然，迭代遷移并不是無(wú)休止地迭代，通常，預(yù)轉(zhuǎn)儲(chǔ)階段的迭代是收斂的，即持續(xù)時(shí)間越來(lái)越短。如果迭代，預(yù)轉(zhuǎn)儲(chǔ)階段通常在達(dá)到預(yù)定迭代次數(shù)時(shí)或者臟頁(yè)閾值時(shí)結(jié)束。因此需要定義一個(gè)明確的內(nèi)存頁(yè)數(shù)，以保證最短的停機(jī)時(shí)間，或者使用一個(gè)固定的迭代次數(shù)，以避免無(wú)限循環(huán)，即頁(yè)面數(shù)量永遠(yuǎn)不會(huì)低于預(yù)先定義的臟頁(yè)閾值。當(dāng)連續(xù)迭代中的增量?jī)?nèi)存檢查點(diǎn)文件的大小低于閾值時(shí)，應(yīng)該開(kāi)始停止并復(fù)制。在此方案中，判斷迭代過(guò)程是否發(fā)散的依據(jù)是本次迭代中增量?jī)?nèi)存的大小是否大于上一次迭代。

3 結(jié)果評(píng)估

3.1 實(shí)驗(yàn)設(shè)置

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

遷移容器所花費(fèi)的總時(shí)間主要由以下幾部分 組成：

（1）預(yù)轉(zhuǎn)儲(chǔ)階段將生成的預(yù)轉(zhuǎn)儲(chǔ)數(shù)據(jù)從源節(jié)點(diǎn)傳輸?shù)侥繕?biāo)節(jié)點(diǎn)的時(shí)間；

（2）在轉(zhuǎn)儲(chǔ)階段將生成的轉(zhuǎn)儲(chǔ)數(shù)據(jù)從源節(jié)點(diǎn)傳輸?shù)侥繕?biāo)節(jié)點(diǎn)的時(shí)間；

（3）遷移到目標(biāo)節(jié)點(diǎn)后容器恢復(fù)的時(shí)間。

服務(wù)的停機(jī)時(shí)間主要由傳輸轉(zhuǎn)儲(chǔ)數(shù)據(jù)導(dǎo)致。

3.2 結(jié)果分析

本文通過(guò)實(shí)驗(yàn)評(píng)估所提方案的性能，并與傳統(tǒng)的冷遷移進(jìn)行了對(duì)比，對(duì)比實(shí)驗(yàn)分別在不同臟頁(yè)變化率和不同帶寬的條件下進(jìn)行，對(duì)比結(jié)果如表1、表2所示。冷遷移的步驟主要分為3步：首先凍結(jié)/停止容器以確保它不在修改狀態(tài)，其次在容器停止時(shí)轉(zhuǎn)儲(chǔ)整個(gè)狀態(tài)并轉(zhuǎn)移它，最后當(dāng)所有狀態(tài)都可用時(shí)，在目的地恢復(fù)容器。

表1 臟頁(yè)變化率為10 KB/s時(shí)的性能對(duì)比

表2 臟頁(yè)變化率為300 KB/s時(shí)的性能對(duì)比

從總遷移時(shí)間角度分析，無(wú)論何種網(wǎng)絡(luò)情況、何種臟頁(yè)變化率，冷遷移的總遷移時(shí)間最長(zhǎng)，因?yàn)樵摲椒](méi)有考慮容器的分層存儲(chǔ)特性，每次進(jìn)行服務(wù)遷移時(shí)，遷移整個(gè)容器到目標(biāo)節(jié)點(diǎn)，傳輸?shù)臄?shù)據(jù)量遠(yuǎn)遠(yuǎn)超過(guò)所提方案。但是，當(dāng)臟頁(yè)變化率提高一個(gè)量級(jí)之后，所提方案的總遷移時(shí)間在網(wǎng)絡(luò)條件較差的環(huán)境下與冷遷移接近，這是因?yàn)槔溥w移在遷移過(guò)程中不考慮內(nèi)存頁(yè)變化，它總是將容器整體打包傳輸給目標(biāo)節(jié)點(diǎn)，所有的內(nèi)存頁(yè)只傳輸一次。而所提方案考慮將內(nèi)存頁(yè)迭代遷移，在臟頁(yè)變化率增大的情況下，預(yù)轉(zhuǎn)儲(chǔ)階段被弄臟的頁(yè)面數(shù)量與該階段轉(zhuǎn)移的頁(yè)面數(shù)量相當(dāng)，導(dǎo)致內(nèi)存頁(yè)傳輸了不止一次，預(yù)轉(zhuǎn)儲(chǔ)遷移的數(shù)據(jù)轉(zhuǎn)儲(chǔ)量相當(dāng)大。在網(wǎng)絡(luò)條件理想的情況下，雖然臟頁(yè)變化率增大，但是遠(yuǎn)不及網(wǎng)絡(luò)吞吐量，所以轉(zhuǎn)儲(chǔ)階段遷移不受影響。

從停機(jī)時(shí)間角度考慮，無(wú)論何種網(wǎng)絡(luò)情況、何種臟頁(yè)變化率，冷遷移的停機(jī)時(shí)間最長(zhǎng)，幾乎與其總遷移時(shí)間吻合。這是因?yàn)槔溥w移和預(yù)轉(zhuǎn)儲(chǔ)遷移之間的主要區(qū)別在于其轉(zhuǎn)儲(chǔ)的性質(zhì)，冷遷移中的轉(zhuǎn)儲(chǔ)代表整個(gè)容器狀態(tài)，因此始終包括所有內(nèi)存頁(yè)面和執(zhí)行狀態(tài)。相反，預(yù)轉(zhuǎn)儲(chǔ)遷移中的轉(zhuǎn)儲(chǔ)僅包括在預(yù)轉(zhuǎn)儲(chǔ)階段修改的那些內(nèi)存頁(yè)面，以及執(zhí)行狀態(tài)的更改；因此，預(yù)轉(zhuǎn)儲(chǔ)遷移的停機(jī)時(shí)間比冷遷移的停機(jī)時(shí)間短。但是冷遷移的遷移性能不受臟頁(yè)變化率的約束，在同樣的網(wǎng)絡(luò)條件下停機(jī)時(shí)間幾乎一致。而所提方案在網(wǎng)絡(luò)條件較差、臟頁(yè)變化率變高的條件下，停機(jī)時(shí)間增加明顯，性能下降，原因在于此情況下臟頁(yè)變化率數(shù)量級(jí)更接近帶寬，導(dǎo)致最終轉(zhuǎn)儲(chǔ)的臟頁(yè)數(shù)量增多。但是當(dāng)所提方案在網(wǎng)絡(luò)條件理想的情況下，停機(jī)時(shí)間不受臟頁(yè)變化率的影響，這是因?yàn)樵谶@些條件下，很少有內(nèi)存頁(yè)在預(yù)轉(zhuǎn)儲(chǔ)階段被修改，所提方案在轉(zhuǎn)儲(chǔ)階段傳輸?shù)臄?shù)據(jù)量幾乎一致。

4 結(jié)語(yǔ)

容器化和容器遷移是邊緣計(jì)算的一個(gè)基本方面，移動(dòng)邊緣計(jì)算是一種范式，在網(wǎng)絡(luò)邊緣附近提供計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)的資源及服務(wù)。本文批判性地分析了現(xiàn)有的容器遷移技術(shù)，并特別關(guān)注它們對(duì)邊緣計(jì)算環(huán)境的適用性，結(jié)合現(xiàn)有的遷移技術(shù)和工具，提出了基于容器分層特性的預(yù)轉(zhuǎn)儲(chǔ)遷移方案，該方案利用容器的鏡像層與容器層分離的特性，在遷移過(guò)程根據(jù)目標(biāo)節(jié)點(diǎn)的實(shí)際情況，只傳輸缺失的鏡像層，以此減少網(wǎng)絡(luò)負(fù)擔(dān)。在考慮到遷移過(guò)程的停機(jī)時(shí)間時(shí)，本文采用預(yù)轉(zhuǎn)儲(chǔ)方法，在遷移開(kāi)始前迭代遷移內(nèi)存頁(yè)，以此減少轉(zhuǎn)儲(chǔ)過(guò)程中傳輸?shù)臓顟B(tài)信息，降低服務(wù)遷移停機(jī)時(shí)間。最后在實(shí)驗(yàn)平臺(tái)上對(duì)該方案進(jìn)行了全面的性能評(píng)估，觀察它在不同的網(wǎng)絡(luò)條件和頁(yè)面變臟率條件下的遷移性能。在評(píng)估了總遷移時(shí)間、停機(jī)時(shí)間后，結(jié)果表明所提方案表現(xiàn)優(yōu)異，在網(wǎng)絡(luò)條件理想的情況下，停機(jī)時(shí)間接近1 s。

在未來(lái)工作中，將繼續(xù)探索容器的服務(wù)遷移方法，利用人工智能的手段來(lái)決定和執(zhí)行服務(wù)遷移的觸發(fā)時(shí)間，以提高方法的性能。