基于DPU的容器冷啟動加速解決方案

1.?方案背景

1.1.?業(yè)務背景

隨著容器技術的迅猛發(fā)展與廣泛應用，一種新的云計算服務模式應運而生-函數(shù)即服務（FaaS, Function as a Service）。FaaS作為一種無服務器（Serverless）計算方式，極大地簡化了開發(fā)人員的工作，使他們能夠專注于應用的構建與運行，而不再需要承擔服務器管理的負擔。

然而，F(xiàn)aaS模式也并非沒有缺陷，其中最為人詬病的便是“冷啟動”問題。所謂冷啟動，是指當請求被調度到某個函數(shù)實例時，如果該實例在上次執(zhí)行完代碼后已經(jīng)被回收，系統(tǒng)需要先創(chuàng)建一個新的實例并初始化環(huán)境，才能繼續(xù)執(zhí)行代碼。

相比之下，熱啟動則是指函數(shù)實例未被回收的情況下，直接復用現(xiàn)有實例以響應請求，這顯然效率更高。因此，冷啟動過程常常導致較高的延遲，進而影響應用的性能。

1.2.?問題與挑戰(zhàn)

1.2.1 傳統(tǒng)方案

根據(jù)《Slacker: Fast Distribution with Lazy Docker Containers》一文的分析，鏡像拉取過程占據(jù)了容器啟動時間的76%，然而實際啟動時只有6.4%的數(shù)據(jù)會被讀取。這一現(xiàn)象揭示了傳統(tǒng)容器鏡像格式和拉取方式在使用overlay文件系統(tǒng)（OverlayFS）時存在的問題：

• 過多的時間花費在拉取鏡像上。
• 拉取了過多無關的數(shù)據(jù)。

這兩個問題的根源在于容器鏡像是由一組tgz文件組成，而這些文件作為鏡像層（image layer）存在以下兩個顯著缺點：

• 提取單個文件時，需要掃描整個layer。
• 同一層多個文件的提取不支持并行處理。

因此，使用OverlayFS的容器在啟動前必須完成所有tgz文件的拉取和解壓，這無疑增加了啟動時間。

針對這些問題，社區(qū)已經(jīng)提出了一些改進措施，具有代表性的兩個解決方案是Stargz和DADI。

1.2.2 已有的改進方案

Stargz 是一種容器鏡像加速技術，它采用了 Google的CRFS（Container Registry Filesystem）來重新組織容器鏡像，以便實現(xiàn)更快的容器啟動和更高效的文件檢索。CRFS是一個只讀的用戶態(tài)文件系統(tǒng)，它使用了新的文件格式，使得鏡像層內(nèi)的文件可以被隨機訪問（seekable）。

stargz架構圖

使用Stargz啟動容器時，無需拉取所有層到本地，而是遠程掛載每一層到本地目錄組成rootfs，從而實現(xiàn)容器的快速啟動。容器啟動之后的數(shù)據(jù)訪問則是利用FUSE(用戶態(tài)文件系統(tǒng))按需獲取。

DADI(Data Accelerator for Disaggregated Infrastructure)是阿里云針對容器加速的解決方案，DADI 的核心組件是 Overlaybd，這是一種基于塊設備的鏡像格式，提供了在block-based layer之上的一個合并視圖，然后通過TCMU在Host上產(chǎn)生一個SCSI設備作為rootfs。TCMU（Target Core Module In Userspace），是scsi target的用戶態(tài)實現(xiàn)，用于生成一個容器 rootfs 的 SCSI 設備。

DADI架構圖

使用DADI啟動一個容器時，其也不用拉取所有層到本地，只是基于所有層塊設備創(chuàng)建一個scsi device表示rootfs，實現(xiàn)容器的快速啟動。容器啟動之后的數(shù)據(jù)訪問則是由tcmu按需獲取，并且加入了本地緩存和ZFile加速數(shù)據(jù)的讀取。

1.2.3 問題總結

綜上所述，以上方案在實際應用中仍然存在以下問題：

• 傳統(tǒng)OverlayFS容器的冷啟動時間較長，這可能會對性能敏感的應用造成影響，導致較差的用戶體驗。
• 改進方案中的用戶態(tài)文件系統(tǒng)需要占用一定的主機資源，這可能會對系統(tǒng)的整體性能產(chǎn)生影響。

2.?方案介紹

2.1.?整體架構

為了解決上述問題，我們構建了基于DPU的容器冷啟動解決方案，以k8s為底座，以存儲為核心，利用DPU的卸載和加速能力，使容器的冷啟動更快，占用更少的host資源。整體架構如下所示：

1-4）：containerd會調用yusur-snapshotter準備rootfs每一層的內(nèi)容快照，image-mgmt根據(jù)label參數(shù)連接存儲，創(chuàng)建spdk bdev。

5-9）：到最后一層時，需要創(chuàng)建NVMe subsystem/ctrl/ns，關聯(lián)spdk bdev，此時在host側給相應PCI綁定NVMe驅動，即可看到對應的NVMe disk。

10）：yusur-snapshotter查到disk之后，按照不同的鏡像格式生成容器啟動的rootfs。

采用本方案啟動容器時，首先DPU會通過NVMe/RDMA的方式連接遠端存儲，實現(xiàn)高效的數(shù)據(jù)傳輸，然后通過NVMe PCIE的方式直通給host，最后host基于這個直通的disk生成rootfs并啟動容器。由于云盤原生支持按需讀取的特性，本方案在容器啟動過程中無需拉取鏡像，從而顯著加快容器的啟動過程。

2.2.?方案描述

當使用本方案啟動容器時，首先需要進行鏡像轉換，鏡像轉換的主要作用是將原始鏡像按照 Lvol（邏輯卷）的方式落地到存儲中，并將鏡像元數(shù)據(jù)推送至鏡像倉庫，供容器啟動時使用。

同時本方案在鏡像轉換時支持兩種鏡像格式y(tǒng)usur-overlayfs和yusur-overlaybd。yusur-overlayfs和原生的鏡像格式一樣，按照overlay的方式生成rootfs，主要用于兼容overlay的場景；yusur-overlaybd以塊設備的方式作為rootfs，原生支持可寫層和理論上性能較overlayfs好。

2.2.1.?鏡像轉換

鏡像轉換主要責任是基于SPDK snapshot機制把原生鏡像按需轉換成以上兩種格式的鏡像，鏡像數(shù)據(jù)存到存儲，元數(shù)據(jù)存到鏡像倉庫。鏡像轉換有兩種工作模式：普通模式和DPU模式。在DPU模式下，能利用DPU的加速能力，可以顯著加快鏡像轉換的速度。

普通模式的架構如下圖所示，其組件主要包含image-ctrl，attacher service，opi-spdk-bridge和原生spdk。

紅色線條表示數(shù)據(jù)走向，job拉取原鏡像層數(shù)據(jù)，按不同鏡像格式寫到nbd設備中。各個組件的作用如下：

• Image-ctrl，鏡像控制器：接收鏡像轉換yaml，創(chuàng)建轉換job。job負責創(chuàng)建塊存儲，調用attach service創(chuàng)建和克隆lvol，完成鏡像層數(shù)據(jù)寫入lvol和推送轉換后鏡像元數(shù)據(jù)至倉庫。
• Attacher service：對opi-bridge操作的抽象，對上提供opi-bridge的能力
• Opi-spdk-bridge：對接原生SPDK的opi-bridge，提供原生SPDK的基本操作
• SPDK：原生SPDK提供快照，克隆的能力

DPU模式的架構如下圖所示，其組件主要包含image-ctrl，image-mgmt，attacher ，opi-bridge和DPU spdk。

紅色線條表示數(shù)據(jù)走向，job拉取原鏡像層數(shù)據(jù)，按不同鏡像格式寫到NVMe disk中，各個組件的作用如下：

• Opi-bridge：提供不通DPU的存儲能力API
• SPDK：不同DPU的SPDK 服務，提供NVMe disk的模擬功能

2.2.2.?鏡像格式

使用兩種鏡像創(chuàng)建容器時，處理流程基本一致，差異在鏡像數(shù)據(jù)的組織方式和rootfs的組成方式，yusur-overlayfs鏡像格式如下所示。

如上圖所示，鏡像X:A完成鏡像轉換之后，生成數(shù)據(jù)A，鏡像X:B在轉換時直接使用這部分數(shù)據(jù)，鏡像X:B其他數(shù)據(jù)基于克隆的lvol寫入。共享數(shù)據(jù)可以包含一個或多個lvol，它們之間也是通過clone鏈接在一起。

yusur-overlaybd的鏡像格式如下圖所示，與yusur-overlayfs鏡像每層數(shù)據(jù)寫到lvol不同目錄的方式不同，yusur-overlaybd的鏡像數(shù)據(jù)會直接寫入lvol。

兩種鏡像格式的rootfs組成如下圖所示。

yusur-overlaybd以nbd設備作為rootfs，不用額外的可寫層；而yusur-overlayfs是以塊設備中的多個目錄作為lowerdir，然后加一個可寫層作為upperdir構成rootfs。

2.2.3.?容器啟動

容器啟動流程請參考”整體架構”章節(jié)。當用轉換鏡像啟動容器時，containerd會根據(jù)鏡像元數(shù)據(jù)生成一些labels，這些labels會作為參數(shù)傳遞給yusur-snapshotter，yusur-snapshotter會根據(jù)這些labels，創(chuàng)建不同的存儲target。

目前支持兩種形式的存儲target，本地AIO和遠程NVMe-OF，NVMe-OF同時又支持兩種連接方式NVMe/TCP和NVMe/RDMA。在容器啟動過程中主要涉及以下組件yusur-snapshotter，image-mgmt service和attacher service，作用如下：

• Yusur-snapshotter：實現(xiàn)containerd的snapshotter接口，負責準備容器啟動的rootfs
• Image-mgmt service：和snapshotter交互，以AIO或NVMe-OF的方式創(chuàng)建和掛載塊設備。

3.?方案測試結果

3.1.?功能測試

3.1.1.?鏡像轉換

創(chuàng)建鏡像轉換CR之后，控制器就會創(chuàng)建job進行鏡像轉換。以下是yusur-overlayfs和yusur-overlaybd轉換成功的截圖：

轉換成功之后，會更新CR status，blocks會包含目的鏡像對應存儲的卷，多個卷之間是以clone的方式遞進，以yusur-overlayfs為例，如下所示：

轉換成功之后，目的鏡像會推送至鏡像倉庫，其作用是在容器啟動時，提供存儲相關的元數(shù)據(jù)，如下所示：

Annotation中包含該層所在的塊設備，鏡像格式，文件系統(tǒng)等信息，這些信息會作為labels傳遞給yusur-snapshotter。

3.1.2.?Pod啟動

pod啟動之后，可以查看rootfs組成，如下所示：

Yusur-overlayfs:

overlayfs格式的鏡像，塊設備中包含鏡像的每一層數(shù)據(jù)，掛載后把相關層目錄，bind到對應的snapshot，構成overlay的lowerdir。

Yusur-overlaybd:

overlaybd格式的鏡像, 塊設備中包含鏡像的rootfs；沒有把塊設備直接作為容器啟動的rootfs，考慮到還需要一個可寫層，所以基于塊設備創(chuàng)建一個qcow2的本地文件，然后本地文件通過nbd暴露出來，作為容器啟動的rootfs和可寫層。

3.2.?性能測試

性能測試包括5種方案，本方案提供了其中的兩種yusur-overlayfs/NVMe/RDMA和yusur-overlaybd/NVMe/RDMA。yusur-overlayfs/NVMe/RDMA表示鏡像格式是yusur-overlayfs，存儲target是NVMe-OF，連接方式是RDMA；yusur-overlaybd/NVMe/RDMA同yusur-overlayfs，只是鏡像格式不同。

3.2.1.?Containerd下的容器啟動耗時測試

我們將測試整個容器啟動過程中的時間消耗，具體分為三個階段：鏡像拉取、容器創(chuàng)建和服務ready。

如上圖所示，縱坐標表示容器ready時間（單位：秒），橫坐標表示鏡像名稱。由于此場景只是去掉了k8s的影響，結論同2.2.1, 如下：

• 本方案的yusur-overlayfs較overlayfs有63%的性能提升，因為不用拉取所有數(shù)據(jù)到本地；
• 本方案的yusur-overlaybd較DADI overlaybd有34%的性能提升，是因為本方案io路徑更短。

如上圖所示，可以得出如下結論：

• overlaybd鏡像拉取是最快的，因為overlaybd在這個過程中只生成TCMU的config文件；
• 本方案的兩種方法都較overlaybd慢，是因為本方案在鏡像拉取中需要掛載云盤。
• ?stargz也比overlaybd慢，是因為stargz在鏡像拉取中需要掛載用戶態(tài)文件系統(tǒng)?

如上圖所示，可以得出如下結論：

• 由于 OverlayFS 的數(shù)據(jù)已經(jīng)在本地，因此 OverlayFS 的容器創(chuàng)建時間僅包括 runc 的操作以及啟動命令的時間。
• 本方案的兩種方法中，容器創(chuàng)建時間較高，因為本方案的 rootfs 基于 DPU 提供的云盤，yusur-snapshoter 需要創(chuàng)建 NVMe 系統(tǒng)（前端）并執(zhí)行找盤操作。
• stargz 在 CentOS 上消耗的時間較多，是因為 stargz 需要預加載（在這里需要預拉取 80M 的數(shù)據(jù)，主要時間消耗在這里）。
• ?對于 overlaybd，由于其原理上與本方案基本相同，都是利用文件系統(tǒng)實現(xiàn)按需拉取，因此時間上基本差不多。

如上圖所示，可以得出如下結論：

• 容器gcc消耗時間基本沒有，是因為gcc啟動命令只是執(zhí)行了gcc --version，這個在容器創(chuàng)建時，已經(jīng)就執(zhí)行完了
• OverlayFS 的耗時最短，因為在鏡像拉取階段，鏡像數(shù)據(jù)已經(jīng)被下載并存儲在本地
• Stargz由于前一過程預拉取了部分數(shù)據(jù)，所以總體時間上略高于OverlayFS。
• 本方案的 yusur-overlaybd 優(yōu)于 overlaybd，主要是因為它在后期數(shù)據(jù)讀取方面表現(xiàn)更佳。與 overlaybd 需要通過 TCMU 定位文件偏移量并使用 HTTP Range Request 向 registry 請求數(shù)據(jù)的方式不同，本方案直接通過內(nèi)核 VFS，并采用 NVMe/RDMA 的方式進行數(shù)據(jù)傳輸，因而具有更低的延遲。
• 本方案的 yusur-overlayfs 相較于 stargz 和 overlayfs 表現(xiàn)稍遜，主要原因在于 overlayfs 的數(shù)據(jù)已存儲在本地，而 stargz 在容器啟動前已完成熱點數(shù)據(jù)的預提取，而本方案則缺少數(shù)據(jù)預提取這一過程。

3.2.2.?鏡像轉換耗時測試

由于兩種鏡像格式相差不大，故采用 yusur-overlayfs 作為對比，測試結果如下所示：

如上圖所示，縱坐標表示不同模式下鏡像轉換時間（單位：秒），橫坐標表示鏡像名稱。可以得出如下結論：

• 基于DPU的鏡像轉換方案可以降低鏡像轉換的時間，但是效果不是太明顯。不明顯的原因是受制于后端存儲CEPH，導致RDMA發(fā)揮不出優(yōu)勢。

3.3.?資源消耗測試

3.3.1.?CPU消耗測試

stargz兩次測試結果：如圖所示，CPU最高使用率20.17%，平均使用率4.22%。

overlayfs兩次測試結果：如圖所示，CPU最高使用率14.77%，平均使用率2.78%。

overlaybd兩次測試結果：如圖所示，CPU最高使用率11.4%，平均使用率3.27%。

yusur-overlayfs兩次測試結果：如圖所示，CPU最高使用率7.66%，平均使用率1.95%。

yusur-overlaybd兩次測試結果：如圖所示，cpu最高使用率10.02%，平均使用率2.17%。

整體使用率較yusur-overlayfs高，從system使用率觀察可以得出是nbd這一層導致的。

匯總結果如下：

從以上所有圖片，得出如下結論：

• 本方案的最高CPU使用率最低;
• 本方案的cpu高利用率維持時間最短，只有30s左右。

3.3.2.?內(nèi)存消耗測試

stargz兩次測試結果：如圖所示，最高內(nèi)存使用7.67G，平均內(nèi)存使用6.86G。

overlayfs兩次測試結果：如圖所示，最高內(nèi)存使用5.71G，平均內(nèi)存使用5.16G。

overlaybd兩次測試結果：如圖所示，最高內(nèi)存使用5.21G，平均內(nèi)存使用4.94G。

yusur-overlayfs兩次測試結果：如圖所示，最高內(nèi)存使用5.28G，平均內(nèi)存使用4.87G。

yusur-overlaybd兩次測試結果：如圖所示，最高內(nèi)存使用5.62G，平均內(nèi)存使用5.01G。

匯總結果如下：

從以上所有圖片，得出如下結論：

• 本方案的消耗的內(nèi)存最低；
• 本方案的內(nèi)存高消耗維持時間最短，只有60s左右。

4.?總結

4.1.?測試結果總結

• 在 K8s 場景下，本方案的 yusur-overlayfs 相比于傳統(tǒng)方案 overlayfs，性能提升了 57%；而相比改進方案 DADI，yusur-overlaybd 的性能也提升了 20%
• 在 Containerd 場景下，本方案的 yusur-overlayfs 相比傳統(tǒng)方案 overlayfs，性能提升了 63%；而 yusur-overlaybd 相較于改進方案 DADI，性能也提升了 34%。
• 控制面和數(shù)據(jù)面下沉至 DPU，有效減少了主機資源的消耗。從測試結果來看，本方案的 CPU 和內(nèi)存占用率以及持續(xù)時間均為最低。
• 從鏡像cypress-chrome（624.2 MiB）、centos(1.3GiB)、tensorflow-notebook(1.7 GiB)的啟動時間看，在本方案中，容器冷啟動時間隨著鏡像大小的增加，其時間優(yōu)勢變得越加明顯。
• 從鏡像轉換的測試結果來看，鏡像越大，基于 DPU 的方案在時間上表現(xiàn)出越明顯的優(yōu)勢，因為它能夠利用 DPU 的 RDMA 能力。類推到容器啟動過程中，所需的數(shù)據(jù)量越大，本方案的優(yōu)勢也會越加顯著。

4.2.?方案價值

基于DPU的容器冷啟動加速解決方案具有如下價值：

1、提升服務響應速度和用戶體驗：在FaaS中，由于函數(shù)實例是動態(tài)創(chuàng)建的，首次調用函數(shù)時可能會遇到冷啟動延遲，即容器從停止狀態(tài)到運行狀態(tài)所需的時間?？焖倮鋯蛹夹g能夠顯著縮短這一時間，使得用戶請求能夠更快地得到響應，從而提升用戶體驗。

2、提高業(yè)務吞吐量：快速冷啟動使得FaaS平臺能夠在短時間內(nèi)啟動更多的函數(shù)實例，以應對突發(fā)的流量高峰，從而提高業(yè)務的整體吞吐量。

3、提高系統(tǒng)可用性：在微服務架構和分布式系統(tǒng)中，服務的快速冷啟動可以確保在服務實例故障時，能夠迅速恢復服務，減少服務中斷時間，提高系統(tǒng)的整體可用性。

4、提升資源利用效率：控制面和數(shù)據(jù)面下沉至 DPU，有效減少了主機資源的消耗，這意味著在實際應用場景中，將大大節(jié)省了寶貴的CPU和內(nèi)存資源，讓這些資源能夠被應用服務更高效地利用。

綜上所述，基于DPU的容器冷啟動加速解決方案對于提升服務響應速度和用戶體驗、提高業(yè)務吞吐量、提高系統(tǒng)可用性、提升資源利用效率等方面都具有重要的價值和意義，隨著云原生和無服務器計算的不斷發(fā)展，該方案將具有廣闊的應用前景。

本方案來自于中科馭數(shù)軟件研發(fā)團隊，團隊核心由一群在云計算、數(shù)據(jù)中心架構、高性能計算領域深耕多年的業(yè)界資深架構師和技術專家組成，不僅擁有豐富的實戰(zhàn)經(jīng)驗，還對行業(yè)趨勢具備敏銳的洞察力，該團隊致力于探索、設計、開發(fā)、推廣可落地的高性能云計算解決方案，幫助最終客戶加速數(shù)字化轉型，提升業(yè)務效能，同時降低運營成本。