![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/bb1cb793c62a4059a89ac7645c550a46.png)

作者 |陳博
來源 | [阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/7sLCUwX1amNqJ0LIi4WEZw)

近日阿里巴巴開源了其[雲原生容器映象加速技術](https://github.com/alibaba/accelerated-container-image)，它推出的 overlaybd 映象格式，相比於傳統的分層 tar 包檔案格式，實現了基於網路的按需讀取，從而使得容器可以快速啟動。

該技術方案原本是阿里雲內部 DADI 專案的一部分， DADI 是 Data Accelerator for Disaggregated Infrastructure 的縮寫，旨在為計算儲存分離架構提供各種可能的資料訪問加速技術。映象加速是 DADI 架構在容器及雲原生領域的一次突破性嘗試，該技術自 2019 年投產以來，已線上上部署了大量機器，累計啟動容器次數超過 10 億，支援了阿里巴巴集團及阿里雲的多個業務線，極大提高了應用的釋出和擴容效率。2020 年，團隊在國際頂級會議發表了論文"DADI: Block-Level Image Service for Agile and Elastic Application Deployment. USENIX ATC'20"[1]，並隨後啟動了開源專案，計劃將技術該貢獻給社群，透過建立標準並打造生態，吸引更多的開發者投入到容器及雲原生效能最佳化這個領域上來。

# 背景簡介
隨著 Kubernetes 和雲原生的大爆發，容器在企業內部的大規模應用已經越來越廣泛。部署啟動快是容器的核心優勢之一，這個啟動快是指本地映象例項化的時間非常短，即“熱啟動”時間短。然而對於“冷啟動”，即在本地無映象的情況下，需要先從 Registry 下載映象才能建立容器。業務的映象經過長期維護和更新，無論是映象層數還是整體大小都會達到一個較大的量級，比如可能達到數百 MB 或者幾個 GB。因此生產環境中，容器的冷啟動往往耗時數分鐘，並且隨規模擴大會導致 Registry 因叢集內網路擁堵而無法快速地下載映象。

例如，在之前某年的雙十一活動中，阿里內部一個應用因為容量不足觸發緊急擴容，但因併發量過大，整體擴容耗時較長，這期間對部分使用者的使用體驗造成了影響。而到了 2019 年，隨著 DADI 的部署上線，新映象格式的容器在“映象拉取+容器啟動”上耗費的總時間比普通容器縮短了 5 倍，且 p99 長尾時間更是比後者快了 17 倍。

如何處理儲存在遠端的映象資料，這是解決容器冷啟動慢這個問題的核心點。歷史上業界對這一問題做出的嘗試有：使用塊儲存或者NAS儲存容器映象，實現按需讀取；使用基於網路的分發技術（如 p2p），將映象從多個源頭下載、或者提前預熱到主機上，避免出現網路單點瓶頸。近年來，針對新映象格式的討論也逐漸被提上議題，根據 Harter 等人的[研究](https://www.usenix.org/conference/fast16/technical-sessions/presentation/harter)表明，拉取映象佔用了容器啟動時間的 76%，而只有 6.4% 的時間用來讀取資料。因此，支援 On-demand Read 技術的映象，已經成為預設的潮流風向。Google 提出的 [stargz](https://github.com/containerd/stargz-snapshotter) 格式，其全稱是 Seekable tar.gz，顧名思義，可以有選擇地從存檔中搜尋並提取特定的檔案，無需掃描或者解壓整個映象。stargz 旨在提高映象拉取的效能，其延遲拉取技術（lazy-pull）不會拉取整個映象檔案，實現了按需讀取。為了進一步提高執行時效率，stargz 又推出了一個 containerd 的 snapshotter 外掛，在儲存層面對 I/O 做了進一步最佳化。

在容器的生命週期中，映象就緒後需要掛載（mount），而分層映象掛載的核心技術便是 overlayfs，它以一種堆疊的形式將下層的多個 layer 檔案合併，並向上暴露出一個統一的只讀檔案系統。類比上文提到的塊儲存和 NAS，一般可以透過快照的形式進行分層堆疊，而跟 stargz 繫結的 CRFS，也可以看做是 overlayfs 的另一種實現。

# 新映象格式
DADI 沒有直接使用 overlayfs，或者說，它只是借鑑了 overlayfs 和早期聯合檔案系統（union filesystem）的思想，但提出了一種全新的基於塊裝置的分層堆疊技術，稱之為 overlaybd，它為容器映象提供了一系列基於塊的合併資料檢視。overlaybd 的實現十分簡單，因此很多之前想做而不能做的事都可以成為現實；而實現一個完全 POSIX 相容的檔案系統介面則充滿挑戰，並可能存在 bug，這點從各個主流檔案系統的發展歷史上就可以看出。

除了簡單以外，overlaybd 對比 overlayfs 的其他優點有：

- 避免多層映象導致的效能下降，如 overlayfs 模式下大檔案的更新會觸發跨層引用複製，系統必須先將檔案複製到可寫層；或者建立硬連結速度很慢等問題。
- 可以方便地採集 block 級別的 I/O 模式，進行錄製以及重放，從而預取資料，進一步加速啟動。
- 使用者的檔案系統和宿主機 OS 可以靈活選擇，如支援 Windows NTFS。
- 可以使用有效的編解碼器進行線上解壓縮。
- 可以下沉到雲中的分散式儲存（如 EBS）中，映象系統盤可以跟資料盤使用同一套儲存方案。
- overlaybd 具有天然的可寫層支援（RW），只讀掛載甚至可以成為歷史。

# overlaybd 原理
為了理解 overlaybd 的原理，首先需要了解容器映象的分層機制。容器映象由多個增量 layer 檔案組成，在使用時進行疊加，這樣在映象分發時只需要對 layer 檔案進行分發。每一層實質上都是與上一層的差異（包括檔案的新增，修改或刪除）的壓縮包。容器引擎可以透過其 storage driver，按照約定的方式將差異疊加起來，然後以 Read-Only 的模式掛載到指定目錄，該目錄即稱為 lower_dir；而以 Read/Write 模式掛載的可寫層，掛載目錄則一般稱為 upper_dir。

請注意，overlaybd 本身沒有檔案的概念，它只是將映象抽象為虛擬塊裝置，並在其上裝載常規的檔案系統。當使用者應用讀取資料時，該讀取請求首先由常規的檔案系統處理，將請求轉換為虛擬塊裝置的一次或多次讀取。這些讀取請求會被轉發到使用者態的接收程式，即 overlaybd 的執行時載體，最後轉換為對一個或多個 layer 的隨機讀取。

與傳統映象一樣，overlaybd 在內部仍然保留著 layer 分層的結構，但每層的內容都是檔案系統變更差異對應的一系列 data block。overlaybd 向上提供了一個合併檢視，對 layer 的疊加規則很簡單，即對於任意一個 data block，總是使用最後的變更，在 layer 中未發生變更的塊均視為全零塊；向下又提供了將一系列 data block 匯出成一個 layer 檔案的功能，該檔案高密度非稀疏、且可索引。因此，對塊裝置某個連續 LBA 範圍進行讀操作，可能包含了原本屬於多層的小塊資料段，我們將這些小塊資料段稱為 segment。從 segment 的屬性中找到層號，便能夠繼續對映到對這層的 layer 檔案的讀取上來。傳統的容器映象可以將它的 layer 檔案儲存在 Registry 或者物件儲存上，那麼 overlaybd 映象自然也可以。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/819cdddb028f46d39f726209ad743d30.png)

為了更好的相容性，overlaybd 在 layer 檔案的最外層，包裝了一層 tar 檔案的頭和尾，這樣偽裝成一個 tar 檔案。由於 tar 內部僅一個檔案，不影響按需讀取。目前無論是 docker、containerd 或者 buildkit，對映象的下載或上傳預設都有 untar 和 tar 的流程，不侵入程式碼是無法逾越的，所以增加 tar 偽裝有利於相容性和流程的統一，例如在映象轉換、構建、或者全量下載使用時，都無需修改程式碼，只需提供外掛即可。

# 整體架構

![2.png](https://ucc.alicdn.com/pic/developer-ecology/b6b883c5db924553bf2d479138268780.png)

DADI 整體架構如圖，以下分別介紹各個元件：

## 1. containerd snapshotter
containerd 自 1.4 版起，開始初步支援一些啟動遠端映象的功能，並且 K8s 已經明確將放棄 Docker 作為執行時的支援。所以 DADI 開源版本選擇優先支援 containerd 生態，之後再支援 Docker。

snapshotter 的核心功能是實現抽象的服務介面，用於容器 rootfs 的掛載和解除安裝等操作。它的設計替代了在 Docker 早期版本稱之為 graphdriver 的模組，使得儲存驅動更加簡化，同時相容了塊裝置快照與 overlayfs。

DADI 提供的 overlaybd-snapshotter 一方面能讓容器引擎支援新的 overlaybd 格式的映象，即將虛擬塊裝置掛載到對應的目錄，另一方面也相容傳統 OCI tar 格式映象，讓使用者繼續以 overlayfs 執行普通容器。

## 2. iSCSI target
iSCSI 是一種被廣泛支援的遠端塊裝置協議，穩定成熟效能高，遇到故障可恢復。overlaybd 模組作為 iSCSI 協議的後端儲存，即使程式意外 crash，重新拉起即可恢復。而基於檔案系統的映象加速方案，例如 stargz，則無法恢復。

iSCSI target 是 overlaybd 的執行時載體。在本專案中，我們實現了兩種 target 模組：第一種是基於開源專案[ tgt](http://stgt.sourceforge.net/)，由於其擁有 backing store 機制，可以將程式碼編譯成動態連結庫以便執行時載入；第二種是基於 Linux 核心的 [LIO SCSI target](https://developer.aliyun.com/article/781992)（又稱為 TCMU），整個 target 執行在核心態，可以比較方便地輸出虛擬塊裝置。

## 3. ZFile
ZFile 是我們提供的一種支援線上解壓的資料壓縮格式。它將原始檔按固定大小的 block size 切分，各資料塊進行單獨壓縮，同時維護一個 jump table，記錄了各資料塊在 ZFile 中的物理偏移位置。如需從 ZFile 中讀資料，只要查詢索引找到對應位置，並僅解壓縮相關的 data block 即可。

ZFile 支援各種有效的壓縮演算法，包括 lz4，zstd 等，它解壓速度極快，開銷低，可以有效節省儲存空間和資料傳輸量。實驗資料表明，按需解壓遠端的 ZFile 資料，效能高於載入非壓縮資料，這是因為傳輸節省的時間，大於解壓的額外開銷。

overlaybd 支援將 layer 檔案匯出成 ZFile 格式。

## 4. cache
正如上文所說，layer 檔案儲存在 Registry 上，容器對塊裝置的讀 I/O 會對映到對 Registry 的請求上（這裡利用到了 Registry 對 HTTP Partial Content 的支援）。但是由於 cache 機制的存在，這種情形不會一直存在。cache 會在容器啟動後的一段時間後自動開始下載 layer 檔案，並持久化到本地檔案系統。如果 cache 命中，則讀 I/O 就不會再發給 Registry，而是讀本地。

# 行業領先
3 月 25 日，權威諮詢機構 Forrester 釋出 2021 年第一季度 FaaS 平臺（Function-As-A-Service Platforms）評估報告，阿里雲憑藉產品能力全球第一的優勢脫穎而出，在八個評測維度中拿到最高分，成為比肩亞馬遜 AWS 的全球 FaaS 領導者。這也是[首次有國內科技公司進入 FaaS 領導者象限](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247503154&idx=1&sn=44325b4efe25a5214143911f24b550ff&chksm=fae6c6fdcd914febc75bc4bacbf90563063df026e1c31fc75cc90dd3db7e126df0eff3145705&scene=21#wechat_redirect)。

眾所周知，容器是 FaaS 平臺的承載基礎，而容器啟動速度更是決定了整個平臺的效能與響應延遲。DADI 助力阿里雲函式計算產品，[大幅度縮短容器啟動時間 50%~80%](http://linux-iscsi.org/)，帶來了全新的 Serverless 使用體驗。

# 總結展望
阿里巴巴開源的 DADI 容器加速專案以及其推出的 overlaybd 映象格式，有助於應對新時代下容器對快速啟動的需求。專案組未來將協同社群一起，加快對接主流工具鏈，積極參與新映象格式標準制定，目標是讓 overlaybd 成為 OCI 遠端映象格式的標準之一。

歡迎大家參與開源專案，一起貢獻力量！

# 後續工作
## 1. Artfacts Manifest
OCI Image 的 v1 Manifest 格式描述能力有限，無法滿足遠端映象需求。目前 v2 的討論沒有實質進展，推翻 v1 也不現實。但是，可以藉助 OCI Artfacts Manifest 使用 Additional Descriptor 來描述原始資料，相容性上有所保證，使用者更容易接受。Artfacts 也是 OCI/CNCF 在推廣的專案，DADI 未來計劃擁抱 Artfacts 並實現 PoC。

## 2. 開放對多種檔案系統的支援
DADI 本身支援使用者根據需要選擇合適的檔案系統來構建映象，但是目前尚未開放相應的介面，預設使用了 ext4 檔案系統。我們未來將完善相關介面並放開此功能，由使用者根據自身需要，決定使用什麼檔案系統。

## 3. Buildkit 工具鏈
目前使用者可以透過 buildkit 外掛 snapshotter 來構建映象，未來將進一步完善，形成完整工具鏈。

## 4. 資料領取
在容器啟動後對 I/O 模式進行記錄，後續啟動同一映象時便可以重放該記錄，對資料進行預取，避免臨時請求 Registry，這樣容器的冷啟動時間將繼續縮短一半以上。理論上所有無狀態或冪等容器都可以進行錄製和重放。

阿里巴巴開源容器映象加速技術

相關文章