查看精彩回放：https://developer.aliyun.com/live/246639
講師：
講解：李慧霸（魯七）
演示：劉蘭崢（南針）
內容簡要：
一、DADI項目簡介
二、容器 image 問題分析
三、DADI方案闡述
四、開源版本現狀與未來計劃
五、視頻演示
一、DADI項目簡介
DADI是Data Accelerator for Disaggregated Infrastructure的首字母縮寫。這個項目關注的是存儲和應用之間的加速層。
我們知道做雲計算的都可以看作是Data Center as a Computer，傳統的Computer是有Cache的,在 CPU和內存之間以及內存和磁盤之間都有Cache，Cache在性能方面扮演了舉足輕重的角色。
到了雲計算場景，我們認為也還是需要Cache，所以DADI就是做應用和存儲系統之間的加速層。但是在分佈式環境，雲計算場景下加速技術並不只有Cache，可能會有更多可能性，比如說像p2p傳輸等。
本次介紹的是 DADI 在容器快速部署場景的應用。
二、容器 image 問題分析
DADI image加速技術已經支持阿里所有自營業務的秒級擴容，是大促必備的產品，並且已經集成進入了公共雲多項容器服務以及容器衍生品服務中。
同時我們還在頂級的學術會議USENIX ATC’20發表了文章，有興趣的朋友們可以通過右上方的二維碼進入論文的主頁：
https://www.usenix.org/conference/atc20/presentation/ li-huiba。
Background: Layered Image of Container
容器image都是需要先從registry下載並且解壓解包，放到本地硬盤上之後才能使用。容器的image由多個層次組成，每一層包含相對於之前狀態的變更集，也就是增加刪除或者修改的文件，這些層合併起來成為一個image， image是隻讀共享的，每個容器自身還包含一個可寫的容器層，這個容器層也包含的是增加或者刪除或者修改的文件，這些容器層之間都是私有的，互相不共享，所有的層次通常使用overlayfs進行合併，供容器內部使用。
Similar to Map Layers
這些容器的層其實和地圖的圖層或photoshop圖層都非常相似。
The Problem
1. 問題在於容器的部署或冷啟動非常緩慢，我們需要事先下載和解壓image，過程通常可以達到幾十秒鐘甚至幾十分鐘。
有研究指出，日誌裡只有平均6.4%的數據是真正使用到的，其餘90%多的數據都是垃圾。這樣一個模式其實讓我們回退到了至少10年以前，那個時候虛擬機的鏡像也是需要下載到各個宿主機然後再使用。
2. 業內有很多解決這個問題的方法，比如說通過p2p的下載方式來加速下載過程，但這樣是不夠的。它只是解決了在大規模情況下的下載速度問題。
對於小規模情況，或者說對於容器 image的解壓縮都是沒有幫助的
3.也有一些工作試圖精簡image，但是精簡工作其實並不能很通用，也並不能很自動，有不少的應用有動態的加載文件的需求，同時精簡過的image也很難支持用戶的一些臨時性的操作需求。
Remote Image
當前image加速技術的主流方向是Remote Image，image放在遠程，可能在registry上或者別的什麼地方，並不需要把它完整下載下來就可以直接開始使用。社區已經有一些方面的工作，比如說CRFS, Teleport, CernVM-FS等。對於大規模集群還需要配合p2p數據傳輸技術才能解決全部的問題。
然而如今image採用了tarball格式，這個格式不支持 remote image，因為它的設計是針對完整解壓縮，不支持我們隨機的seek到一個位置讀取那個位置的數據，同時tarball格式很難支持高級功能，比如說擴展屬性，跨層的數據引用等，所以最好還是重新設計一個新的文件格式。
Type of Image: Block!
擺在我們面前有兩種選擇，一個是基於文件系統的image，就像現代容器image，同時還有一種選擇是用塊設備作為image，就像虛擬機的image一直以來的樣子。我們對這兩種方式做了比較詳細的比較，比較集中在三個方面，一個是複雜度，再一個是通用性，最後是安全性。
我們認為在這三個方面，基於塊設備的image都有非常顯著的優勢，這個優勢最根本上是源於塊設備的image它比較簡單但並不簡陋。我們唯一需要做的是讓塊設備支持分層的特性，相比之下基於文件系統的image，在這些技術方面沒有太多顯著的優勢，可能還會有一些不足。比如說性能會偏低，高級特性會比較缺失等。
三、DADI方案闡述
DADI Remote Image
基於這樣的分析，我們義無反顧選擇了基於塊設備的image格式，第一個contribution是設計了基於塊設備的分層鏡像格式，我們把它稱之為Overlay Block Device。它需要配合常規文件系統比如ext4一起使用給用戶提供文件訪問服務。
第二個contribution是設計了可支持隨機訪問的壓縮文件格式叫ZFile，因為容器鏡像普遍是壓縮存儲，我們不能在這方面留下短板。第三個contribution是我們設計了基於p2p的按需傳輸技術，以應對大規模和超大規模集群的需求。
DADI I/O Path
單機內的I/O路徑如下，首先應用在容器中，讀取文件的請求會傳遞到位於內核的常規文件系統當中，比如ext4，文件系統會把讀請求轉發給一個虛擬塊設備，這個虛擬塊設備使用的是TCMU框架實現，內核的虛擬塊設備會把請求轉發給用戶態的服務進程OverlayBD。
OverlayBD會通過查詢內存中的索引，把讀請求分解為對具體layer的讀取，如果被讀取的layer已經下載到本地，那麼就直接在本地文件系統上來讀取layer。如果layer是新發布的，還沒有下載到本地，那麼就通過 rpc到遠程去訪問。
Overlay Block Device
在DADI image 格式當中，每一個layer就是一個被修改的數據塊的集合，在這個層面上沒有文件或者文件系統的概念，我們每個修改的粒度最小是512字節，和我們常規的塊設備是一致的。同時OverlayBD會維護一個內存索引來實現快速的讀取，索引具有變長和區間查詢的特性，非常高效，它的原理可以用下圖來表示。
在加載image的時候，我們可以一次性的把 image裡所有layer的索引進行合併，合併後一次查詢就能處理任意數量的layer，使得overlayBD的性能不隨layer的增加而下降，只跟合併過後的索引記錄數量有關。
Index Merge
我們統計了生產環境當中大量image的索引合併過後的元素數量，結果如下圖所示，元素數量最多不超過4.5k, 換算到內存佔用不超過100k，我們也測試了單核CPU下能夠提供的處理能力，結果如圖所示，每秒幾百萬次的QPS還是非常充足的。
ZFile
ZFile是支持隨機讀取的壓縮文件格式，它的原理也很簡單，把文件按照固定的數據塊大小一塊一塊地進行壓縮，每次讀取的時候只解壓縮需要的數據塊，不需要的數據塊不解壓縮。同時ZFile格式並不是僅侷限於DADI，它是非常通用的支持隨機訪問的文件格式。
Performance
WordPress Startup with DADI
最後我們來看一下性能，我們最關注的是冷啟動耗時，所以我們最先來測試這一項指標，我們選取了GitHub上的Wordpress鏡像，Wordpress是一個非常流行的CMS系統，它號稱支撐了整個外部世界1/3的網站，所以選用Wordpress具有一定代表性。
結果當中的第一列是普通格式的Wordpress鏡像，我們測試環境當中的Image Pull和App Launch兩個步驟的耗時，總計有10多秒鐘。
第二列測試的是CRFS的相對早期的版本，它的耗時竟然比下載解壓方式更慢一些。
第三列是模仿學術界的Slacker工作，就是把image解壓縮之後放到NFS服務器上，然後從NFS服務器啟動容器，它的耗時顯著比下載解壓的模式要更快一些，只有不到4秒鐘時間。
最後兩列是DADI方案的兩種情況，一個是從Registry的下載數據，另一個是從共享的存儲服務器下載數據，可以看出，DADI的效果要比其他方案好很多。
性能測試，我們分別用du和tar來對image進行掃描, du讀取所有文件的元信息，而tar是讀取所有文件的數據，他們分別側重隨機小塊讀和順序大塊讀的兩種不同的workload。
從I/O性能測試結果來看，DADI也具有顯著的優勢，特別是在使用雲盤的場景下，因為DADI採用的壓縮格式突破了雲盤的帶寬限制，所以取得了更好的效果。
四、開源版本現狀與未來計劃
Open Soure Edition
最後再介紹一下開源版本的狀況，整個項目在GitHub上分成了兩個repo，其中一個主要跟容器世界打交道實現了snapshotter，另一個就是overlaybd,這兩項工作均可以通過右方的鏈接或者二維碼進行訪問。
目前開源的工作當中也包含了鏡像格式轉換工具，可以把已有的tgz格式轉換成DADI格式，我們目前正在做並且近期還會開源的工作包括這麼幾項：
1.bulidkit
2.基於trace的數據預取，可以進一步提高冷啟動速度，尤其是高延遲、高帶寬的場景中。
3.支持ext4之外的文件系統，有些linux發行版已經默認使用xfs，提供更多高級功能，性能也更好，支持多種文件系統有利於提高overlaybd的競爭力。
4.overlaybd 內核模塊，image下載到本地後可以通過內核模塊啟動，這樣I/O路徑就不用經過用戶態再次轉發。
5. 可供應用使用的可寫層。可以擺脫overlayfs的依賴，可以提高性能。
五、視頻演示
演示從DADI Overlaybd格式遠程鏡像來啟動容器的過程。
首先需要完整安裝Overlaybd的運行環境。
Overlaybd有兩個必須的依賴，一個是target_core_user，這是tcmu的內核模塊。第二個依賴是containerd，而且必須是1.4以上的版本。Containerd在1.4版本後支持遠程鏡像拉取，在Image pull的時候，可以不下載全部鏡像數據而只是註冊鏡像，早期的Containerd並沒有這個特性。
Overlaybd有兩個組件事先必須將它們運行起來，分別是overlaybd-snapshotter和overlaybd-tcmu組件。
首先啟動Overlaybd snapshotter，可以直接作為二進制程序運行。
需要說明的是如果是首次使用，必須要修改Containerd的配置，把Overlaybd snapshotter作為一個plugin添加進去。
然後啟動Overlaybd-tcmu組件，這是Overlaybd的Backing Store，也可以作為二進制來運行。啟動之後，它後續日誌將存放在var/log路徑下，需要說明的是我們建議通過服務來管理這兩個組件，這樣即使出現意外也可以重新拉起，Overlaybd本身也支持故障恢復。
下面看一下本次測試的配置文件。
上方是Overlaybd-tcmu的配置文件，首先配置一個4GB大小的本地緩存，路徑為opt/overlaybd/register_catch，遠程鏡像數據加載後會存放到本地緩存，這樣再次請求相同數據時，可以直接從本地緩存獲取，不需要再次通過網絡拉取，測試前我們已經清空了本地緩存。
credentialFilePath是鑑權信息的存放路徑，Overlaybd的鑑權文件需要單獨配置。雖然在拉取鏡像還在Containerd時已經傳入了用戶名密碼，但是遠程拉取的是另一條鑑權路徑，跟Containerd是分開的。如果你的鏡像是私有的，需要事先配置好鑑權文件。
download是後臺下載的配置，我們這次測試將這個功能關閉，如果開啟了這個功能，那麼在鏡像啟動後，會在後臺自動將鏡像數據完整下載到本地。下載完成後，該鏡像變成一個純本地鏡像，再次啟動時，即使斷網也不會受任何影響。
本次測試環境使用的是ACR企業版-ACREE，宿主機使用的是一臺ECS，部署在杭州機房，它們之間的網絡是公網。
本次測試使用的鏡像是wordpress鏡像，我們事先將一個已經轉換為Overlaybd格式的wordpress存放到Registry中。
如上圖所示，我們看一下測試的腳本。
測試腳本首先執行一個rpull指令拉取鏡像。Ctr是Containerd的一個調試工具，它很多功能其實是沒有的，例如Containerd支持遠程鏡像拉取所需要的這些標籤，Ctr本身是沒有的，所以我們在Ctr中擴展了一個新的指令rpull，它可以幫助我們將所需要的標籤傳進去。
對於普通鏡像而言，rpull就是鏡像的下載和解壓。對OverlayBD鏡像，rpull相當於註冊一個鏡像，並不會實際去下載鏡像。然後我們啟動一個容器，這裡必須指明snapshotter使用的是Overlaybd snapshotter。它兼容Overlayfs，對於普通鏡像而言，相當於通過Overlayfs啟動，對於Overlaybd格式的鏡像則進入遠程拉取的邏輯。
下面看一下如何計時。
首先我們看80端口是否就緒，就緒以後檢查wordpress的文件是否可以訪問，如果訪問得到，我們認為服務就緒，停止計時。
我們本次分為三個測試，第一個是普通鏡像的冷啟動測試，第二個是Overlaybd鏡像的冷啟動測試，第三個是Overlaybd的熱啟動測試，分別來看一下三個測試的啟動時間。
1.普通的冷啟動測試
鏡像下載之後進行解壓，我們看到總共的時間接近27秒。然後我們執行一下清理腳本，主要是清空剛才創建的容器和下載的鏡像，並且清除Overlaybd。
2.OverlayBD鏡像的冷啟動測試
拉取耗時0.6秒，接著加載遠程數據，總共用時13秒，速度提升了一倍。下面仍然進行清理，清理的也是鏡像和剛才創建的容器以及系統緩存。但這裡並沒有清理Overlaybd的Cache，所以再次啟動時，需要遠程加載的數據將命中本地緩存。
3.OverlayBD的熱啟動測試
啟動時間是2.3秒，接近於熱啟動本地普通鏡像。
