*作者：徐立

## 雲原生的創新源泉

雲原生趨勢下，應用容器化比例正在快速增長，Kubernetes 也已成為雲原生時代新的基礎設施。 Forrester 預測到 2022 年，全球組織/公司在生產環境執行容器化應用。從今天不足 30%的比例將大幅度提升到超過 75%，企業應用容器化的趨勢勢不可擋。我們可以看到兩個普遍的現象。首先，在雲上託管 Kubernetes 已經成為企業上雲及執行容器的優先選擇。另外，使用者使用容器的方式也在改變，從無狀態應用到核心企業應用再到資料智慧應用，越來越多的企業使用容器來部署生產級別、複雜度高和高效能運算的有狀態應用。比如 Web 服務、內容資料庫、資料庫，甚至 DevOps、AI/大資料應用等。

![1.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5115c8b11e964730bef1820e3609fc3d~tplv-k3u1fbpfcp-watermark.image?)

隨著基礎設施從物理機到虛擬機器，到以 Kubernetes 為代表的容器環境，甚至到 Serverless 的逐漸演進，今天的計算和應用正在面臨巨大的變化。這種變化使得資源粒度越來越細，生命週期越來越短，計算按需使用。

從使用者視角來看雲原生帶來的儲存變化，最明顯的就是使用者使用儲存介面發生上移，和應用不直接相關的儲存服務從應用層下沉到雲平臺，使用者更關心應用。

舉例來說，傳統形態使用者需要關心所有硬體和軟體，逐漸過渡到使用者關心虛擬機器、作業系統和整個應用軟體棧，到今天在 Serverless 裡演變成使用者只關心應用業務和程式碼。系統資源從物理資源層、虛擬化資源層上升到應用開發層，使用者無需關心底層的基礎設施。

在這樣的技術體系下，儲存的能力的演變主要體現在以下 3 個方面：

**1、高密**
虛擬機器時代，一個虛擬機器就對應一個完整的儲存空間，可以用其儲存整個應用所需要的所有資料相關的訪問和儲存需求。在Serverless 函式計算環境，應用被切分為一個個函式，對應的資源都需要儲存管理，因此，儲存的密度發生了很大的變化，儲存密度更高。

**2、彈性**
隨著應用拆分的粒度越來越細化，儲存密度逐漸提升，Serverless 函式計算大規模例項需要高併發啟動，儲存需要極致彈性的能力。

**3、極速**
從Serverless 函式計算的角度來看，函式是整個程式的一個部分，生命週期自然變短。由此出現大量短生命週期的容器例項。隨著生命週期越來越短，需要儲存快速掛載/解除安裝，快速訪問。

隨著服務介面發生上移，儲存管控介面被重塑，內建儲存和外接儲存變得更加清晰。Serverless 環境裡，使用者可見介面是外接儲存（包括檔案儲存和物件儲存），而內建儲存（包括映象儲存和臨時儲存）對使用者是不可見的，內建儲存由阿里雲來管理，提供了創新的機會。

## 映象加速的技術創新

### 阿里巴巴容器規模化部署的挑戰

![2.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b3264edd2e8f4b53a805cab473f5e23c~tplv-k3u1fbpfcp-watermark.image?)

阿里巴巴容器規模化部署主要面臨的挑戰體現在以下幾個方面：

**1、業務體量大。** 叢集規模大，高達十萬量級；所有應用全部容器化，並且應用映象大，通常以數十 GB 大小為主。

**2、更快的部署速度。** 業務規模持續增長，要求雲平臺可以快速的部署應用，才能夠處理業務增長，尤其雙十一大促時緊急擴容，難以事前對各服務準確預估容量。

3、然而大規模的建立或者更新容器叢集依然很慢，主要原因是容器部署映象的下載和解壓很慢，主要的技術挑戰如下:

**• 時間開銷大**：時間開銷 ∝ 映象大小 * 節點數；一千節點就需要存一千份映象；

**• CPU 時間開銷大：** gzip解壓慢，且只能序列解壓;

**• I/O 壓力大：** 下載、解壓兩輪寫盤，包括眾多節點同時寫盤，對雲盤產生“共振”;

**• 記憶體佔用擾動：** 對宿主機 page cache 產生嚴重擾動;

**• 但是有效資料佔比少：** 啟動時平均僅需映象資料的6.4%。

應對以上技術挑戰，大規模容器部署的關鍵需求抽象總結為三點：

**1、按需：** 下載解壓速度足夠快、資料按需訪問和按需傳輸。

**2、增量分層：** 資料解耦，透過 OCI-Artifacts 標準 overlayfs 把層次做劃分，增量資料，時間資源使用更有效。

**3、Remote Image ：** 採用遠端映象技術，改變映象格式，同時減少本地資源的消耗。

### Remote Image 技術方案對比

Remote Image 主要有兩種技術實現的方式，一種是基於檔案系統，第二種是基於塊裝置。Remote Image 技術方案對比如下圖所示：

![3.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d5d4dfd8c51a4170a569d424458b2f91~tplv-k3u1fbpfcp-watermark.image?)

基於檔案系統的 Remote Image 技術的主要特點是直接提供檔案系統介面，是容器 Image 的自然擴充套件。複雜度高，穩定性、最佳化和高階功能的實現難度大。在通用性上，和作業系統繫結，能力固定，不一定匹配所有應用。同時攻擊面較大。行業代表主要是 Google CRFS，Microsoft Azure Project Teleport，AWS SparseFS。

基於塊裝置實現的 Remote Image 技術的主要特點是可配合常規檔案系統一起使用，如 ext4；普通容器、安全容器、虛擬機器均可直接使用。複雜度、穩定性、最佳化和高階功能更容易實現。在通用性上，與作業系統和檔案系統解綁，應用可自由選擇最合適的檔案系統，如 NTFS，作為依賴打包進 Image。並且攻擊面較小。

**阿里巴巴選擇了 Date Accelerator for Disaggregated Infrastructure （簡稱為 DADI），同時進行了規模性驗證。**

## 阿里巴巴自研容器映象加速技術 DADI

DADI 是阿里巴巴的獨創性的技術方案。DADI 映象服務是一種可以做到敏捷又彈性部署應用的分層塊級映象服務。DADI 徹底摒棄了傳統容器啟動的瀑布型別（即下載、解包、啟動），實現了遠端映象的細粒度按需載入，容器啟動前不在需要部署映象，容器在建立後可以立即啟動。

DADI 的資料路徑如下圖所示，虛線之下是核心態，虛線之上是使用者態。DADI 將映象抽象為虛擬塊裝置，並在其上容器應用掛載常規檔案系統如 ext4。當使用者應用讀取資料時候，讀取請求先透過常規的檔案系統處理，檔案系統將請求轉換為虛擬塊裝置的一次或者多次讀取。對塊裝置的讀取請求被轉發到使用者態的 DADI 模組，最後轉換為一個或者多個 Layer 的隨機讀取。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fad0ec2c87d34e4c96335c8935c8aa67~tplv-k3u1fbpfcp-watermark.image?)

DADI 映象採用塊儲存+分層技術，每層只記錄被增量修改的資料塊，支援壓縮以及實時的按需解壓縮；支援按需傳輸，只傳輸用到的資料塊下載使用；DADI 還可以採用 P2P 傳輸架構，一傳十、十傳百，在大規模叢集內將網路流量均衡到所有多個節點上去。

### DADI 關鍵技術解讀

DADI 增量映象可以透過基於塊+分層技術來實現，其中每個層對應於一個 LBA 的變更。DADI 的關鍵技術包括遠端映象的細粒度按需傳輸，高效的線上解壓縮，基於 trace 讀取，用於處理突發工作的 P2P 傳輸技術。DADI 在提高部署應用的敏捷性和彈性方面非常有效。

**1、分層塊裝置 Overlay Block Device**

每層記錄被增量修改的變長資料塊 LBA，不涉及檔案/檔案系統的概念，以 512 位元組為最小粒度。快速索引，支援變長記錄，以節省記憶體，各記錄的 LBA 不重疊，支援高效的區間查詢。

**2、原生支援可寫層**

提供追加寫檔案和隨機寫稀疏檔案兩種模式構建 DADI 映象。只讀層，每個只讀都可以按照不同型別的大小，每層查詢區間，速度極快。可寫層由儲存原始資料(Raw Data)和儲存索引(Index)兩部分組成，接受 append only 組織而成。

![5.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c45036d030b64731891e75dd69c079a0~tplv-k3u1fbpfcp-watermark.image?)

**3、ZFile 壓縮格式**

標準壓縮檔案格式，例如 gz，bz2，xz 等，無法高效的進行隨機讀寫操作，無論讀取壓縮檔案中的哪一部分，都需要從頭部開始解壓，為了支援 layer blob 的壓縮並同時支援遠端映象的按需讀取，DADI 引入了 ZFile 壓縮格式。ZFile 的壓縮格式如下圖所示，按固定大小資料塊壓縮，只解壓讀到的資料塊，支援多種有效的壓縮演算法，包括 lz4，zstd，gzip 等，採用通用格式，不繫結於 DADI。

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/211260bc82c743b89be630700dc927a0~tplv-k3u1fbpfcp-watermark.image?)

**4、基於 Trace 預取**

記錄應用過程中的讀取日誌、只記位置、不記資料本身。在應用冷啟動時，若已有 trace 記錄，則 DADI 將根據trace提前把資料預取回本地，採用高併發讀取，更加高效。Trace 作為一個特殊的 layer 存於 image，專門用於加速，使用者不可見，未來可容納其他加速檔案。如下圖綠色部分表示加速層、容納 trace 檔案以及其他檔案。

![6(1).png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/275f4dc88d70428a95c08aab57e1b9ea~tplv-k3u1fbpfcp-watermark.image?)

**5、按需 P2P 傳輸**

在我們的生產環境中，有幾個關鍵應用程式已經部署在數千臺伺服器上，並且包含高達數 GB 的 Layer，這些應用程式的部署給 Registry 和網路基礎設施帶來了巨大壓力。為了更好的處理此類大型應用，DADI 將最近使用的資料塊快取在每個宿主機的本地磁碟上，採用 P2P 的方式在主機之間傳輸資料。

![7.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0c5735b629a442d0823dbf30edbd8247~tplv-k3u1fbpfcp-watermark.image?)

**1、採用樹形拓撲結構分發資料**

• 各個節點均快取最近使用過的資料塊

• 跨節點請求大機率命中父節點自己的 cache

• 未命中的請求會遞迴向上傳遞，直到 registr

**2、拓撲結構由 root 節點動態維護**

• 每個 layer 單獨一個傳輸拓撲

**3、每個機房單獨部署一組 root**

• 多節點高可用架構

• 基於一致性雜湊的分工

### 大規模啟動耗時測試

![8.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/158df651bd3c4b81b2e2cbd1f3211c2b~tplv-k3u1fbpfcp-watermark.image?)

我們將 DADI 容器啟動延遲與 .tgz 映象、Slacker、CRFS、LVM 和 P2P 映象下載進行了比較，使用 DockerHub.com 上的 WordPress 映象，我們觀測單例項的冷啟動延遲，所有伺服器和主機位於同一資料中心。如左圖所示，結果表明，使用 DADI 可以明顯減少容器的冷啟動時間。

我們在公共雲上建立了 1000 個 VM，並將他們用做容器的主機。在每個主機上啟動 10 個容器，總共 10000 個容器。測試使用 Python 編寫的一個小程式 Agility，訪問 HTTP 伺服器並在服務端記錄時間。如右圖所示，結果表明 DADI 的冷啟動在 3 秒之內快速完成。

### DADI 在阿里巴巴的規模化執行

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4f8cc55154934c5ca56405fdf0a1a1cc~tplv-k3u1fbpfcp-watermark.image?)

DADI 已經在阿里巴巴集團規模化執行，在阿里巴巴的生產環境內大規模部署。資料顯示 DADI 在 10000個宿主機上啟動 10000 個容器僅需3-4 秒。DADI 完美應對雙十一大促洪峰，目前在阿里巴巴集團內部已經部署了接近十萬臺伺服器宿主機，支援集團 Sigma、搜尋、UC 等業務線上、離線應用超過 2 萬個，極大提高了應用釋出、擴容效率，體驗如絲般順滑。我們在全球最大的電子商務平臺之一的生產環境中使用 DADI 的經驗表明，DADI 在提高部署應用的敏捷性和彈性方面非常有效。

### 擁抱開源，釋放雲原生技術紅利

現在，DADI 正在透過貢獻社群的方式更好地釋放雲原生技術紅利，也希望與更多企業和開發者共建容器映象標準。

目前 DADI 已經開放了支援 Contained（docker 尚不支援 remote image），支援節點直連 Registry + 本地快取技術，支援構建、轉換映象。

未來還會開放 P2P 按需傳輸：將 P2P 子系統重新設計為 Registry 的延伸，將支援共享儲存，如 nfs、hdfs、ceph、glusterfs 等，全域性 Registry +機房共享儲存 + 節點本地快取 + P2P 資料傳輸，構建機房內快取。

大家可透過檢視以下 Github 的連結瞭解更多資訊：

- 控制平面 (for containerd)：

https://github.com/alibaba/accelerated-container-image

- 資料平面(overlaybd)：

https://github.com/alibaba/overlaybd

## 容器持久儲存的技術演進

### 儲存接入技術面臨的挑戰

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/13d4455356234e32953f5d27fe38abe8~tplv-k3u1fbpfcp-watermark.image?)

上面我們談到了 Serverless 應用架構的新正規化，現在我們看到一個趨勢，從虛擬機器到普通容器，再逐漸演變為神龍裸金屬部署安全容器。從儲存的佈局角度來看，其面臨的顯而易見的挑戰是更加高密和多租戶。

**容器接入技術趨勢：** 計算層基於 ECS + 普通容器的架構向基於神龍 + 安全容器架構演進，單節點密度達到 2000，單例項規格最小粒度記憶體 128MB，1/12 CPU。容器接入技術的趨勢，帶來了 I/O 資源放大的挑戰。

阿里雲端儲存在端接入上有自己的思考，儲存分為內建儲存(映象和臨時儲存)和外接儲存（檔案系統/共享檔案系統、大資料檔案系統、資料庫檔案系統等）。

儲存系統如何和底層更好的連線？儲存接入容器的方式是透過 virtio 的能力解除安裝到神龍Moc 卡上，神龍 Moc 卡 + virtio 的通路和底層儲存服務更好的聯動。

## 持久儲存 - 面向現代化應用的彈性供給雲盤 ESSD

![11.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4373960473684870bd9f2d1fb3e31ad9~tplv-k3u1fbpfcp-watermark.image?)

ESSD 雲盤為使用者提供高可用、高可靠、高效能的塊級隨機訪問服務，並提供原生快照資料保護和跨域容災等豐富的企業特性。

面向現代化應用的彈性供給雲盤 ESSD 具備兩個關鍵特性：
- 雲盤掛載密度提升 4 倍，單例項最大支援 64 塊雲盤
- 效能與容量完全解耦，使用者需求不需要預先設定，按需而定。

舉例來說，為了應對很多使用者面臨的問題：無法準確預估業務峰值，在效能配置上難以做好精準規劃。如果效能配置預留過高，會造成日常資源的大量閒置浪費；而如果效能預留不足，業務突發洪峰會造成業務受損。我們推出了 **ESSD Auto PL** 雲盤，它支援效能指定配置的同時，支援按業務負載自動伸縮，單盤可以自動提升到最高 100 萬 IOPS 效能，為不可預期的突發訪問提供安全便捷的效能自動配置。

## 持久儲存 - 容器網路檔案系統 CNFS

針對容器中使用檔案儲存的優勢和挑戰，阿里雲端儲存團隊與容器服務團隊共同推出了容器網路檔案系統 CNFS，內建在阿里雲託管的 Kubernetes 服務 ACK 中。CNFS 透過將阿里雲的檔案儲存抽象為一個 K8s 物件（CRD）進行獨立管理，包括建立、刪除、描述、掛載，監控及擴容等運維操作，使使用者可以在享受容器使用檔案儲存帶來的便捷的同時，提高檔案儲存的效能和資料安全，並提供容器一致的宣告式管理。

![12.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b217a006a59344e5b6b0fab0e8a256d6~tplv-k3u1fbpfcp-watermark.image?)

CNFS 在可訪問性、彈性擴容、效能最佳化、可觀測性、資料保護、宣告式等六個方面針對容器儲存進行了深度最佳化，使其與開源方案相比具有以下明顯優勢：

- 在儲存型別方面，CNFS 支援檔案儲存，目前支援阿里雲檔案儲存 NAS
- 支援 Kubernetes 相容的宣告式生命週期管理，可以一站式管理容器和儲存
- 支援 PV 的線上擴容、自動擴容，針對容器彈性伸縮特性最佳化
- 支援更好的和 Kubernetes 結合的資料保護，包括 PV 快照、回收站、刪除保護、資料加密、資料災備等
- 支援應用級別的應用一致性快照，自動分析應用配置和儲存依賴，一鍵備份、一鍵還原
- 支援 PV 級別監控
- 支援更好的訪問控制，提高共享檔案系統的許可權安全，包括目錄級 Quota、ACL
- 提供效能最佳化，針對檔案儲存的小檔案讀寫，提供更最佳化的效能
- 成本最佳化，提供低頻介質及轉換策略，降低儲存成本

## 最佳實踐

### 資料庫容器化使用 ESSD 雲盤高密掛載的最佳實踐

![13.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/590b3f4e98364b80aaf0a92c11b961ba~tplv-k3u1fbpfcp-watermark.image?)

資料庫容器化使用 ESSD 雲盤高密掛載的業務場景主要面臨的需求是：資料庫部署模式從虛擬機器向容器化發展，持續提升彈性和可移植性，簡化部署。容器部署密度隨著 CPU 核數線性增長，需要持久化儲存提升掛載密度。資料庫作為 IO 密集型業務，對單機儲存效能提出更高要求。

我們的解決方案是資料庫使用 g6se 儲存增強型例項，單例項提供最高 64 塊雲盤掛載密度，g6se 儲存增強型例項，提供最高 100 萬 IOPS，4GB 儲存吞吐，適配單機高密部署的效能需求。

資料庫容器化使用 ESSD 雲盤高密掛載的優勢是：

- 高密掛載：相比上代例項，雲盤掛載密度提升 400%，提升資料庫例項單機部署密度。
- 高效能：單機最高 100 萬 IOPS，多個雲盤之間 IO 天然隔離，提供穩定可預期讀寫效能。
- 高彈性：ESSD 雲盤 支援 IA 快照，快照立即可用實現只讀例項的秒級建立。
- 高可靠性：雲盤基於 9 個 9 資料庫可靠性設計，同時支援快照、非同步複製等資料保護手段，解決軟硬體故障帶來的資料安全風向。

### Prometheus 監控服務使用檔案儲存的最佳實踐

![14.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cbb3d773243a4b9a983f5e565960e8d4~tplv-k3u1fbpfcp-watermark.image?)

Prometheus 的實現方式是Prometheus server 主要用於抓取和儲存資料。Client libraries 可以用來連線 server 並進行查詢等操作，push gateway 用於批次，短期的監控資料的歸總節點，主要用於業務資料彙報等。不同 exporter 用於不同場景下的資料收集，如收集 MongoDB 資訊 MongoDB exporter。

Prometheus 的核心儲存 TSDB ，類似 LSM tree 的儲存引擎。我們看到一個趨勢，儲存引擎多節點資料同步，需要引入 Paxos 一致性協議。中小型客戶在管理引擎的時候，管理一致性協議的時候難度非常大，架構將計算和儲存分離，計算是無狀態的，TSDB 的儲存的引擎釋放給分散式檔案系統，天然需要 NAS 共享檔案系統。

Prometheus 監控服務使用檔案儲存的優勢是：

- **共享高可用：** 多 Pod 共享 NAS 持久化儲存，計算節點 Failover 實現容器應用的高可用。
- **0 改造：** 分散式 POSIX 檔案系統介面，無需任何改造
- **高效能：** 支援併發訪問，效能滿足瞬間拉起索引查詢，同步進行資料載入以及低時延索引查詢 + 寫入
- **高彈性：** 儲存空間不需預配置，按需使用，按量計費，適配容器彈效能力

## 總結

面向容器和 Serverless Computing 的儲存創新發展驅動了儲存視角的新變化，整個儲存介面上移，開發者更加專屬於應用本身，基礎設施的運維儘量被託管。儲存供給的特性更加高密、彈性、極速。

以上為大家分享了阿里雲容器儲存的技術創新，包括 DADI 映象加速技術，為容器規模化啟動奠定了很好的基礎，ESSD 雲盤提供極致效能，CNFS 容器網路檔案系統提供極致的使用者體驗。

隨時雲原生創新序幕拉開，雲原生儲存創新剛剛走出第一步，相信和各位行業專家一起開創和 Reinvent 儲存的創新機會。

更多關於阿里雲容器網路檔案系統 CNFS 的技術能力、應用場景和使用方式，**請點選**[“閱讀原文”](https://yqh.aliyun.com/live/ack_cnfs_release)**瞭解。**

阿里雲徐立：面向容器和 Serverless Computing 的儲存創新

相關文章