前言
“鴻蒙初判陶镕鐵，大禹神人親所設。湖海江河淺共深，曾将此棒知之切。開山治水太平時，流落東洋鎮海阙。日久年深放彩霞，能消能長能光潔。老孫有分取将來，變化無方随口訣。要大彌于宇宙間，要小卻似針兒節。棒名如意号金箍，天上人間稱一絕。重該一萬三千五百斤，或粗或細能生滅。也曾助我鬧天宮，也曾随我攻地阙。伏虎降龍處處通，煉魔蕩怪方方徹。舉頭一指太陽昏，天地鬼神皆膽怯。混沌仙傳到至今，原來不是凡間鐵。”
--《西遊記》
從自研的分布式檔案系統 “盤古” 開天辟地之後，阿裡雲經過 10 年的發展已經在 IaaS+PaaS 産品能力排名上位居東半球第一，世界第三，在計算、存儲、網絡、安全等方面已經處于領先水準。而雲計算差別于傳統伺服器架構除了成本和可靠性以外，彈性能力也是一個突出的優勢。恰如有萬千變化的金箍棒一樣，與計算的彈性能力為使用者提供随心順意的業務擴充能力，助客戶從容面對各種業務伸縮場景。
2021年7月27日，在可信雲大會上，中國資訊通信研究院釋出了《虛拟化雲平台性能評估方法》，并宣布阿裡雲成為首個通過“虛拟化雲平台性能測試（大規模）”的雲廠商，獲得“2021可信雲技術服務大規模最佳實踐”的稱号。在本次測試的彈性子產品中，在信通院從業人員的見證下，阿裡雲使用彈性伸縮工具，在 1106秒（約18分）内完成了1萬台（日常使用場景單次擴容峰值）雲伺服器的擴容
【6】。
圖一 虛拟化雲平台性能測試通過證書
像如意金箍棒需要在老君爐内的不斷曆練一樣，塊存儲極緻的彈性能力也經曆了多次疊代才至臻完善。本文會結合業務場景講述塊存儲彈性能力這根金箍棒背後的技術和故事。
彈性伸縮的需求
基于網際網路的應用有很多共性的特點會對雲計算有彈性伸縮的需求：
-
業務規模大
使用者可以利用互聯的普及和快速傳播的特點，可以快速實作業務規模的擴充。同時會帶來更多的計算和存儲資源需求。現在諸如 12306 鐵路購票系統、微網誌等新媒體、淘寶購物、短視訊和本地生活等業務越來越多地實作了雲化部署。是以對雲計算有快速、規模化部署的需求
-
突發流量大
網際網路業務極易産生熱點通路，比如春運和黃金周等時段數以億計地對火車票的操作需求、微網誌和短視訊的熱點搜尋通路，以及 6.18、雙十一等商業大促行為都會對既有的網際網路業務有快速擴充的需要。同時熱點過後，回歸正常業務流量之後也需要對業務進行縮容，避免閑置，降低企業營運成本。因為對雲計算有快速擴容、縮容的彈性需求
綜上，業務的彈性伸縮能力在雲計算的場景有一個遞進式的需求：
- 業務的彈性能力
業務自身需要能夠根據業務的流量情況調整自身業務的規模，包括業務關聯的多個應用的彈性伸縮調整
- 應用的彈性能力
應用的彈性依賴于自身的快速部署、啟動以及流量切流的能力
- 伺服器的彈性能力
不論基于 ECS 執行個體還是容器，都是對底層伺服器彈性伸縮能力的需求，即資源的快速申請和釋放、快速啟動和執行個體化等。
阿裡雲提供的彈性能力包含兩個典型的架構：基于 IaaS 的 ECS 執行個體
【5】和基于 PaaS 的 ECI 執行個體。這兩種架構的彈性伸縮能力最本質的是對底層雲伺服器的擴容和縮容。對于塊存儲來說，這個彈性能力就是從鏡像按需為這些伺服器批量建立塊裝置-雲盤，典型場景如下：
- ECS執行個體快速啟動
- 雲遊戲和離線計算場景資料盤批量建立和挂載
- ECI 容器批量啟動
圖二 執行個體和容器場景下彈性能力的需求轉化為底層伺服器雲盤的彈性能力
極緻彈性背後的技術
阿裡雲快照技術
快照業務簡介
快照作為雲盤的增值服務為雲盤提供某一時刻的靜态資料備份。快照的存儲方式分為叢集本地存儲和對象存儲（OSS）。快照提供豐富的業務生态，包括資料備份、復原、克隆（建立雲盤）、 DevOps、安全掃描、無代理備份以及快照直接讀寫等。同時快照作為阿裡雲彈性計算（ECS）鏡像的底層實作，支援鏡像的導入、導出以及虛拟機啟動、容器擴容和雲盤批量克隆等功能。
圖三 快照業務簡介
快照的原理
塊存儲快照是基于資料版本和資料差異來實作。對雲盤邏輯空間按照固定的大小進行分塊（Block）後為每一個 Block 配置設定一個标号（Block ID）。同時每一個 Block 具有一個版本号（Version）用于記錄 Block 資料的修改版本。當雲盤上的 Block 被修改之後存儲端會記錄該 Block 狀态為髒（Dirty），而快照作為雲盤某個時間點資料的備份就是對這些标髒的 Block 進行備份并提升這些 Block 的 Version。具有相同 Version 的 Block 屬于同一個快照一緻性點。
塊存儲快照分為全量快照和增量快照。全量快照為快照一緻性點時雲盤上所有非空 Block 的集合，而增量快照包含相對于父快照的差異 Block，即快照一緻性點時雲盤上所有與父快照 Block 版本号不相同的 Block 集合。同時增量快照中與父快照相同的 Block 通過引用的方式建構出完整的邏輯位址空間視圖。
下圖顯示了不同快照類型中資料版本與資料塊的引用關系。
圖四 快照的原理
ECS 鏡像原理
底層資料采用快照格式進行存儲，同時在管控層面附加諸如大小、格式等鏡像中繼資料資訊來實作。是以我們也支援從快照直接轉換為鏡像，對鏡像的操作基本等同于快照操作。
快照的存儲方式
阿裡雲塊存儲是建構在更底層的分布式檔案系統（盤古）之上，所有的資料以盤古檔案的方式進行存儲。從雲盤層面看資料是按照一定大小分成若幹個區域（Segment）進行組織。根據邏輯空間按照 Segment 大小将雲盤劃分為 N 個 Segment，并且多個 Segment 按照一定的條帶配置構成條帶組（如2MB*4，即條帶寬度 2MB，4 個 Segment 一組）。在同一個條帶組中的 Segment 按條帶依次寫入。一塊雲盤Segment 的主要檔案包括兩大類：資料檔案（Data File）和索引檔案（Index File），其中資料檔案用于存儲實際的雲盤資料，而索引檔案用于映射雲盤 LBA（邏輯位址空間 Logical Block Address）在資料檔案中位置和大小。
快照建立的原理是通過 Hark Link 的方式使快照與雲盤共享資料檔案，并且通過一個快照的索引檔案（Index File）記錄快照資料 LBA 在資料檔案（Data File）中的位置。此時所有快照的資料均位于存儲叢集内（本地快照副本，Snapshot Copy）。與此同時，我們對快照的邏輯空間按照固定大小進行分塊後離線上傳到對象存儲（OSS）中獨立的 Object 檔案進行備份（OSS 快照）。
圖五 快照的存儲方式
Lazyload 技術
傳統的虛拟機技術，鏡像資料要存儲虛拟機的主控端本地，之後虛拟機通過本地的鏡像資料進行啟動。虛拟機挂載的資料盤也是類似情況，資料需要存儲于主控端本地才能正常工作。
阿裡雲塊存儲采用延遲加載（Lazyload）技術實作資料按需讀取和背景下載下傳，使從鏡像/快照建立的雲盤在建立操作完成之後立即進行讀寫，這樣可以無延遲地快速啟動虛拟機或使用新建立的雲盤。
鏡像資料 Lazyload 是對快照空間按照固定資料塊大小分塊後下載下傳的，分為兩種類型：
- 背景下載下傳 雲盤建立完成後拉起的背景資料下載下傳任務，順序從 OSS 下載下傳非空的資料塊到叢集本地來建立快照副本（Snapshot Copy），并在後端服務儲存 LRU 的資料塊緩存。
- Lazyload Read 由雲盤的讀 IO 觸發的下載下傳請求。此時待讀取的雲盤 LBA 所在的資料塊還沒有通過背景任務下載下傳過，是以會高優先級地從 OSS 拉取對應的資料塊，并加入到 LRU 緩存
圖六 快照 Lazyload 技術
快照克隆原理
從鏡像/快照/備份建立新的雲盤的實作原理可以劃分為以下兩種：
圖七 快照克隆技術原理
| Solution 1 | Solution 2 | |
| 實作原理 | 每塊雲盤從對象存儲或者冷存儲單獨下載下傳快照資料 | 同一個快照叢集内隻下載下傳一份資料并建立為快照副本。所有雲盤通過 Hard Link 方式實作對快照副本資料共享 |
| 資料下載下傳流量 | 從對象存儲或冷存儲直接讀取，總流量為快照有效資料量與雲盤數量乘積 | 整個叢集最多隻從對象存儲下載下傳一份資料。創盤時如果有本地副本則不再下載下傳。總流量為快照有效資料量 |
| 叢集本地存儲 | 各雲盤資料獨立，叢集占用容量與雲盤數量成正比 | 多雲盤共享同一快照副本資料 |
| 相關産品 | EBS 1.0 | EBS 2.0 |
通過上面的快照克隆方案的對比可知，阿裡雲塊存儲新版本的克隆方案創新地通過快照副本共享的方式為所有雲盤提供資料，使從快照批量創盤對網絡流量的占用從與雲盤數量成線性關系變為常量，以數個數量級地減少了對存儲叢集 NC 網絡的沖擊。同時也極大地節省了存儲叢集的空間，特别是針對以讀為主的批量計算雲盤和容器鏡像緩存用途的雲盤建立場景。
批量克隆能力優化
快照下載下傳速度
從前面的介紹可知，快照在 OSS 是按照固定大小的資料塊進行存儲的，在快照下載下傳時為了提高下載下傳速度以達到縮短對雲盤 IO 毫秒級影響的目的，我們對快照資料采用多任務并行下載下傳的方式拉取快照資料到叢集本地副本中。 每個下載下傳任務可以提供至少 20MB/s 的下載下傳帶寬，并發任務的上限為 64 個，單快照的下載下傳速度可以達到 1.28 GB/s。阿裡雲典型的鏡像大小為 20~60 GB，基本上資料下載下傳時間 16~47 秒。
快照格式轉換
雲盤和快照資料都是按照 Segment 來組織的，但是快照和雲盤出于不同的考慮，比如多任務并發下載下傳快照資料，導緻快照的 Segment 大小遠小于雲盤的 Segment 大小。是以叢集中快照副本的 Segment 沒有辦法直接進行轉換為雲盤的 Segment，需要一次資料導入（Import）将快照資料導入到雲盤中。
快照資料導入的方式是通過 Load 快照 Segment 後分析快照 LBA 與資料檔案存儲的對應關系來确定哪些資料檔案是雲盤 Segment 所需，之後通過 Hard Link 的方式把快照 Segment 下的資料檔案 Link 到雲盤 Segment 中的。由于在分布式檔案系統-盤古上諸如 Hard Link 之類的檔案 Meta 操作是通過叢集單點 Master 來處理的，如果每個雲盤在導入快照資料的時候都進行如此多的檔案 Meta 操作會打爆 Master 的處理能力，進而造成整個叢集的 Meta 處理時延變長，大量積壓的資料 Import 請求造成批量創盤長尾和創盤時間過長。
考慮到所有雲盤共享共一個快照副本資料，各雲盤的 Segment 與快照 Segment 資料檔案的對應關系是相同的，是以我們隻需要為一個雲盤計算映射關系，其他雲盤直接複用就可以。是以我們在快照資料下載下傳完成之後把快照的格式按照目标雲盤的格式進行轉換，是快照和雲盤 Segment 變成一一對應的關系。再有快照資料為隻讀資料，很多針對于雲盤設計的校驗可以跳過，這樣就大大減少了檔案 Meta 操作數量，以及整體 import 的性能。
經過格式轉換，我們的檔案 Meta 操作數量減少了 70%，Segment資料導入的平均時間縮短了一半以上，是以單快照在單叢集的每分鐘創盤數量提高了 6 倍以上。
圖八 快照副本格式轉換
快照副本資料打散
由于多個雲盤共享同一份快照副本資料，所有雲盤對相同 LBA 的讀取會轉換為對快照副本某個 LBA 的讀取請求。按照之前的介紹，快照和雲盤都是按照條帶寫入的，以 2MB 寬的條帶為例，該條帶内的資料一定會包含在同一個快照 Segment 的資料檔案中，而預設的快照檔案副本數為 3 個，是以一個 2MB 範圍内的資料通路預設隻能從 3 個副本檔案中進行讀取，這樣就在負責 3 個副本檔案 Chunk 讀寫的的盤古服務角色 ChunkServer 上造成讀熱點。直覺的結果會導緻 Slow IO 或者 IO hang。
為了解決這個問題，我們需要對快照資料進行進一步打散。在不改變 2MB 條帶寬度的情況下，我們在寫入 2MB 資料到快照 Segment 的時候采用 Round-Robin 的方式分别寫入 8 個資料檔案，是以同一個 2MB 範圍資料可以有 8 * 3 = 24 個副本可供資料讀取，在原來基礎上打散效果提升了 8 倍。
除此之外，我們還會有另外兩中手段對快照資料副本進行打散：
- 根據單快照創盤數量調整快照資料檔案副本數量
- 根據單快照創盤數量新增快照本叢集副本（Snapshot Copy）與新建立雲盤共享資料
圖九 快照副本資料打散
塊存儲彈性能力的最佳實踐
ECI容器業務批量啟動
現在越來越多的網際網路業務已經從傳統的通過虛拟機形式部署轉變為利用容器技術進行部署。企業對雲計算的彈性能力的需求也從對雲盤批量克隆的需求轉換為對容器執行個體的彈性能力的需求。如何從同一個鏡像快速啟動容器執行個體也就成展現彈性能力的關鍵。本節會介紹塊存儲彈性能力如何助力阿裡雲 ECI 快速啟動的最佳實踐。
相關産品詳見參考文獻【
2】容器啟動過程分析
容器部署業務的一大優勢就是容器執行個體化的速度比重新拉起一台 ECS 執行個體更快速，但是這個啟動過程包含兩種情況：利用 Host 本地鏡像執行個體化容器和從 Registry 現拉取鏡像檔案到本地後執行個體化容器，下面從操作啟動和容器執行個體化的過程對啟動分析的耗時進行分析。
作業系統啟動分析
我們對主流的作業系統和阿裡雲使用量最大的鏡像進行了ECS 執行個體啟動的測試，分析的 IO Pattern 如下：
- Linux 作業系統啟動讀取數量為 200MB 左右
- Windows 作業系統啟動讀取資料量為 380MB 左右
- 讀 IO 的大小以 2 ~ 64KB 為主 (2KB/4KB/16KB/32KB/64KB)
- 讀 IO 分布 2MB 範圍内的集中讀（占比 20%），和1GB 範圍内的離散讀（占比 80%）
詳細的測試結果如下：
| 鏡像 | Linux | Windows | ||
| CentOS 8.3 x64 | AliLinux 3.2104 x64 | Window 2019 x64 | Windows 2016 x64 | |
| 鏡像大小 | 20GB | 40GB | ||
| 資料讀取量 | 184.8MB | 208MB | 377.2MB | 367.5MB |
| LInux 啟動需要 200MB 左右（SSH 成功） | Windows 啟動需要 380MB 左右（RDP 成功） | |||
| Offset 通路分布 | | | | |
| IO Pattern |
|
|
|
|
|
容器鏡像啟動資料
根據 Tyler Harter(University of Wisconsin—Madison) 等人對容器啟動過程的分析
【1】可知容器啟動過程中 76%的時間用于鏡像拉取和解壓縮鏡像分層資料，而與此同時鏡像檔案中隻有的 6% 是容器啟動所必須的。這個資料與我們實測的結果也是比較接近的。
圖十 容器啟動過程資料量和時間占比和鏡像啟動容器測試結果
啟動分析結論
綜上，原生的容器啟動過程需要把容器鏡像拉取到本地之後執行個體化容器，而鏡像中真正用于啟動的資料量很小。業界對于容器啟動加速的辦法都是對鏡像進行緩存來實作。下面我們介紹下塊存儲實作容器鏡像緩存的方案。
塊存儲的鏡像緩存方案
行業内鏡像緩存方案的核心思路是實作對鏡像的按需讀取之後緩存鏡像資料，比較成熟的方案有 Nydus
【3】，DADI
【4】等，他們是通過自定義鏡像格式實作資料按需讀取。而阿裡雲的快照技術本就是 ECS 執行個體啟動所需鏡像的底層實作，我們可以利用快照技術把容器的鏡像轉化為快照，之後通過快照按需快速建立大量雲盤提供的彈性能力在容器大批量啟動時挂載包含鏡像資料的雲盤到容器作為鏡像目錄啟動。
塊存儲的雲盤随機通路能力和延遲加載（Lazyload）技術可以天然的實作對容器鏡像檔案的按需讀取。同時塊裝置的資料存儲于存儲端，既無需在計算端進行資料緩存，也不需要在計算端按照額外元件。此外，由于在鏡像制作的時候已經完成了對鏡像資料的解壓縮和合并，對于計算端的 CPU 等資源幾乎是沒有任何依賴。
以下是塊存儲的鏡像緩存方案與原生鏡像拉取方式的對比：
| 方案 | 容器社群方案 | 塊存儲鏡像緩存 |
| 架構圖 | | |
| 原理 |
|
|
| 按需讀取 | 否 | 是 |
| 計算端緩存資料 | ||
| 計算端解壓縮 | ||
| 計算端侵入元件 |
優化效果
ECI 的鏡像緩存最終采用的是塊存儲的鏡像緩存方案，并且經過對快照批量建立雲盤能力的提升後作為容器啟動的主要優化點助力 ASK+ECI 方案在與友商的直接對話中獲勝并赢得了新媒體領先企業的彈性擴容訂單。
圖十一 容器 POD 啟動時間優化效果
未來展望
容器業務場景下更強的彈性能力
阿裡雲塊存儲會對 ECI 容器鏡像緩存的方案做進一步優化。在堅持對計算端無侵入和無額外的計算資源需求的前提下進一步優化鏡像建立雲盤時所需的 Meta 操作，提高容器啟動時從容器鏡像批量建立雲盤的彈性能力，為容器業務提供更快速、更強大的業務彈性能力。
極速可用的彈性伸縮
利用本地快照實作鏡像極速可用
目前不論是 ECS 執行個體鏡像還是 ECI 容器鏡像的制作都是依賴于 OSS 快照來作為底層存儲。鏡像資料需要上傳到 OSS 完成之後才可以進行批量建立雲盤或者容器啟動。鏡像的制作過程根據鏡像資料多少往往需要較長的時間。是以需要在進行彈性伸縮之前提前預留鏡像制作時間。
從前面的快照技術的介紹可知，本地快照通過 Hardlink 的方式來實作，快照資料存儲于叢集本地，無需等待資料上傳到 OSS，整個建立過程秒級完成。同時本地快照可以在背景離線轉換為 OSS 快照，在滿足極速可用的同時仍然可以利用快照的複制功能實作多 Region 間的鏡像分發和共享能力。是以我們利用本地快照作為鏡像底層資料存儲可以實作鏡像極速可用，實作鏡像制作和快照創盤彈性伸縮能力的無縫銜接。
利用鏡像預熱實作大量雲盤快速建立
目前快照建立雲盤通過資料共享的方式實作，單快照建立雲盤數量超過門檻值時會帶來單一資料副本通路流量集中的熱點問題，并且同一快照無法建立不同類型雲盤（加密/非加密，不同條帶）。此外，新建立雲盤在各個存儲叢集内由于實際庫存情況影響無法做到根據快照引用數量進行均衡排程。
未來我們會提供雲盤預熱的功能，即預先下載下傳快照資料并在各存儲叢集内根據快照創盤的數量調整快照副本數量，使批量建立的雲盤在集中讀資料的時候可以有效地進行流量打散。并且我們可以在預熱時調整叢集的庫存來對新建立雲盤進行均衡排程，提高并發創盤的數量。同時我們的鏡像預熱可以根據目标雲盤的類型為同一個快照建立不同類型的副本。是以，利用鏡像預熱功能我們可以實作單一可用區從一個快照快速建立數萬雲盤，并且支援多種不同類型的雲盤。
參考文獻
【1】容器啟動分析
https://www.usenix.org/conference/fast16/technical-sessions/presentation/harter?spm=a2c6h.12873639.0.0.161a5827i9ZpFl【2】ECI 鏡像緩存
https://help.aliyun.com/document_detail/273116.html【3】Nydus 鏡像加速
https://developer.aliyun.com/article/776458【4】DADI 鏡像加速
https://developer.aliyun.com/article/783266【5】什麼是雲伺服器 ECS
https://help.aliyun.com/document_detail/25367.html https://blog.csdn.net/weixin_46593167/article/details/119151112