火山引擎雲原生儲存加速實踐

　　導讀：在火山引擎相關的業務中絕大部分的機器學習和資料湖的算力都執行在雲原生 K8s 平臺上。雲原生架構下存算分離和彈性伸縮的計算場景，極大的推動了儲存加速這個領域的發展，目前業界也衍生出了多種儲存加速服務。但是面對計算和客戶場景的多樣性，還沒有一個業界標準的儲存加速實踐，很多使用者在做選型的時候也面臨著諸多困惑。我們在火山引擎上構建了雲原生的儲存加速服務，適配機器學習和資料湖的多種計算場景，致力於給業務提供簡單易用的透明加速服務。

　　 01 雲原生儲存加速訴求　　

　　雲原生業務基礎服務主要可以分為三部分：計算、儲存和中介軟體。

　　頂層是計算業務，大部分都是基於 K8s 底座執行的。在計算底座基礎上會進行一些大資料任務以及 AI 訓練任務，再往上就是各種各樣的計算框架。

　　底層是儲存服務，目前來看存算分離是業界未來的趨勢，對於雲上一些標準的儲存服務，可以分成以下三大類：

　　第一類是物件儲存，主要以 AWS S3 為標品，各個雲廠商在標準能力基礎上也都有一些創新服務；

　　第二類是 NAS，傳統的定位是一個遠端的檔案儲存，現在各個雲廠商基本上也都有標準的 NAS 儲存產品；

　　第三類是各種並行的檔案系統，稱為 PFS，它的設計初衷是支援傳統的企業 HPC 場景，能夠支援大併發和大吞吐的資料讀取。現在在雲上主要用來支援大規模的 AI 訓練場景。

　　中間層是各種儲存中介軟體。因為儲存天生的本地性限制，很多時候無法配合計算業務做大規模併發或者彈性排程。所以業界在整個計算業務和儲存服務之間，又推出了一些儲存和加速的中介軟體。比如 ALLUXIO 就是一個典型的儲存加速的代表，另外 JuiceFS 本身也有很多快取和加速的能力。儲存加速在本質上還是為了給計算業務提供更好的彈性讀寫的能力。　　

　　1. 痛點

　　從業務視角來看，儲存和加速存在如下痛點：

　　第一個痛點是選型。因為各種加速的中介軟體沒有業界統一的標準，每個中介軟體都有一些不同的限制。對於該痛點可以透過以下幾個視角去看，首先是協議的相容性，中介軟體產品對業務呈現怎樣的協議，是物件儲存協議，還是部分相容 POSIX 的協議，還是有100% POSIX 協議；另外，成本模型的差異，同等加速頻寬需要付出的成本價格；第三個是資料格式，儲存底座的資料格式和資料目錄是要透傳給業務，還是在中介軟體重新組裝和轉換。

　　第二個痛點是中介軟體產品的治理。對於儲存加速的中介軟體產品，應該怎樣去做運維和穩定性的保障，在底層儲存服務之間的資料流動，以及quota和qos的管控方面，有沒有一些能力的支援。

　　2. 常見方案　　

　　上圖是當前業界常見的儲存加速方案。

　　第一個是物件儲存+Alluxio，不足之處是 POSIX 的相容性受限。POSIX 的相容性主要受限於物件儲存本身的能力，沒有辦法支援原子目錄的 Rename、目錄刪除以及隨機寫、覆蓋寫、追加寫等功能。優勢在於整體的成本相對還是比較廉價的，因為是基於物件儲存，且 Alluxio 本身是一個透明的資料格式，在物件儲存上看到的目錄結構和資料都可以直接呈現給業務。

　　第二個方案是物件儲存+JuiceFS。這個方案比較大的一個優點是整體的 POSIX 相容性是非常優秀的。整體的成本也比較廉價的，因為它很多時候會用到一些計算機上的本地盤作為快取加速的介質。需要注意的是它的資料格式是私有格式，因為資料儲存在物件儲存上是會切塊的，所以從物件儲存上看不到完整的檔案。這一方案的治理成本因人而異，如果所有的業務都是基於 JuiceFS 服務進行的話，幾乎不需要治理成本。但是如果要在 JuiceFS 和其他儲存服務做一些資料流動的話，就會需要進行很多治理工作。

　　第三個方案是基於各種並行檔案系統的服務。優點是 POSIX 的相容性好、資料格式透明、治理成本低。但是由於使用了一些高效能的元件，在業界的價格相對是比較昂貴的。

　　最後一個方案是，各個雲廠商都推出了物件儲存與 PFS 結合的能力，願景是冷資料存放在物件儲存，熱資料在 PFS。但實際的業務體驗並不是很方便，兩邊的資料流動也需要很多的治理成本。

　　 02 什麼是“好”的儲存加速

　　我們理解的“好”的儲存加速應該滿足支援透明加速、多協議相容、可以彈性伸縮、擁有基礎的資料治理能力等特性。

　　1. 透明加速　　

　　透明加速的訴求之一是需要對服務化的加速能力做到開箱即用，擁有穩定 SLA 的保障，也可以做到按量付費。另一個訴求是對底座儲存的原生協議加速後直接透出給業務，從業務視角可以不需要對程式碼層面進行修改，僅需要做一些配置上的適配調整就能看到底座儲存上原始的目錄結構和資料格式。目前無論是雲端儲存還是企業儲存，各個儲存服務都已經比較成熟了，我們不是要去重新造輪子，只是希望將透明加速能力做好，更好地解決業務上的問題。

　　2. 多協議相容　　

　　基於物件儲存的多協議相容，需要做以下四個方面的最佳化：

　　首先是基礎加速能力，包括支援 S3 協議、目錄樹快取，以及自動回寫到物件儲存的能力；

　　第二是 Rename 最佳化，現在很多雲廠商都支援了單個物件原子的 Rename 操作，主要是對接到單個物件的 Rename API，在一定程度上最佳化目錄 Rename 的效能；

　　第三是 Append 支援，對接雲廠商 Appendable 物件，支援 Close-Open-Append 這種常見的寫入模式；

　　第四是 FUSE 掛載，提供 CSI 支援和 FUSE 掛載高可用能力，在 FUSE 程式崩潰重新拉起後還能繼續保持業務 IO 的延續性。　　

　　在基於物件儲存的這套加速方案上，主要會遇到以下三個問題。

　　第一個問題是 POSIX 的相容性不足，由於很多機器學習訓練作業都是基於標準的 POSIX 檔案系統構建的，所以無法基於這套方案執行。

　　第二個問題是如果使用者想基於這套架構推進業務，那麼很多時候都需要做一些業務層面 IO 模型的改造，這對於演算法工程師來說是很難實現的。

　　第三個問題是由於上述兩方面的限制，很多使用者會把這個方案當成高效的只讀快取進行構建業務，也就限制了這個方案使用價值的上限。　　

　　為了解決以上問題，在調研了市場上的相關產品之後，我們決定基於 NAS 來解決 POSIX 相容性的問題。NAS 作為標準的雲端儲存產品，天生具備完整的 POSIX 能力。透過在加速層適配 NAS 作為儲存底座，做好協議適配和一致性保障工作，解決 NAS 產品本身的頻寬和效能瓶頸。在成本方面，容量型 NAS 的價格比物件儲存要昂貴一點，但整體價效比仍然在可接受範圍內。

　　3. 彈性伸縮　　

　　在加速層還需要實現彈性伸縮的能力，加速元件也需要基於雲原生的架構，因此整個資料面基於 NVME SSD 進行構建，擁有分散式的後設資料，資料面的加速也是基於原生平臺構建的。所以無論後設資料還是資料面，都可以擁有彈性伸縮的能力。

　　4. 資料治理　　

　　資料治理方面需要以下重要特性：

　　自動回寫底座：很多業務在透過加速元件寫入資料的時候，非常關心資料在物件儲存底座上的可見性，因為會有很多下游業務需要依賴上一個業務的輸出檔案才能夠發起後續的業務。所以我們需要有不需要過多人工干預的、確定性的回刷策略。

　　快取策略定製：需要更多快取策略的支援，比如典型的 LRFU、TTL 等，支援業界通用的預熱能力的相關機制。

　　多工隔離：提供一些任務級別的加速保障。

　　快取及時更新：支援接入物件儲存 Event 的主動更新，也支援基於 TTL 機制的被動拉取更新。

　　 03 CloudFS加速實踐　　

　　基於位元組內部業務對以上儲存加速能力的需求，我們推出了一個新的、從位元組內部 HDFS 演進而來的 File System 服務，命名為 CloudFS。CloudFS 的整體技術架構與內部 HDFS 架構本質上是同一套元件在雲上做的一些產品化、小型化和多租戶的封裝。　　

　　CloudFS 除了擁有儲存加速能力以外，也支援原生 HDFS 模式和多資料來源聚合的能力。對於底座來說主要支援的還是物件儲存，NAS 底座目前還在適配開發階段，在上層業務上對接了大資料和 AI 訓練的各個生態及火山引擎的一些技術產品等。

　　1. 後設資料加速　　

　　上圖示例中從訓練容器的視角能夠看到 dataset 裡面有兩個物件。dataset 目錄樹結構的檢視與最底層的物件儲存的目錄結構檢視是一致的。最基礎的技術特性是需要快取物件儲存的目錄結構，並且按需拉取。在後設資料服務裡面，複製了物件儲存的目錄樹結構，但是是用目錄樹層次結構的方式儲存的，而不是物件儲存的平鋪目錄結構。另外，我們訂閱了物件儲存的事件通知用於支援主動更新，主動的事件通知和被動的按需拉取儘可能保證了整個後設資料的一致性。另外，同一個 Bucket 被掛載了多次就可能會存在重複的 Object，我們在後設資料層面對同一個 Object 做了去重，最大化快取空間利用率。

　　2. 資料面快取　　

　　接著介紹一下整個資料面的快取。我們把物件切成多個資料塊，每個資料塊可以有多個 Replica，如圖中的 r1、r2 就是同一個資料庫的兩個 Replica。資料面快取策略是比較懶惰的，只有當使用者資料第一次訪問的時候才會把資料撈上來；同時會支援一個自適應的副本數，根據整個副本的業務負載以及當前快取節點的業務負載去支援自適應的副本數，所以副本數可以根據業務的壓力值進行自調節。在快取管理策略上，採用了 ARC 快取演算法，可以儲存更多的資料，確保熱點資料能夠保留在快取裡面。

　　另外我們也支援了預熱機制，因為很多使用者在跑作業之前，需要將其資料全部儲存在快取裡面，這樣在後續啟動作業的時候就不需要等待的開銷。在具體的預熱方式上是基於 P2P 協議做的一個大規模預熱副本的分發。對於寫快取來說，擁有一個多副本的寫快取機制，可以非同步/同步地回寫到底座上。比如一個 Block 寫完之後會立刻將其重新整理到物件儲存上，但是對於物件儲存的物件來說，關閉這個檔案的時候才能夠看到這個底座上的檔案長度或內容的更新。

　　3. FUSE業務入口改造　　

　　我們對FUSE入口做了一些改造來提升其穩定性。首先是 FUSE virtio 的改造。替換了/dev/fuse，使得效能得到了很大的提升。同時對於FUSE程式坐了一定的高可用保障，在 FUSE崩潰重啟後，可以實時恢復到之前的狀態。所以對於業務IO來說，它可以感受到一點卡頓，但是它的上層不會掛掉，還可以繼續跑。有很多訓練作業是一次性要跑很長時間的，所以對訓練作業的穩定性還是有比較大的收益。另外 FUSE也支援page cache，最大化利用系統的記憶體資源。最後一個特性最佳化是同步 close 檔案，因為FUSE原來的基於/dev/fuse的這套方案，在close檔案的時候，它真正close底層的檔案是非同步的，我們在此基礎上做了同步close檔案的支援，這樣可以更好地確保檔案的可見性。當然了這部分改造需要先安裝一個核心模組，所以目前在火山作業系統裡面，預設標準的veLinux作業系統都已經內建了，如果是其它系統，可能需要去安裝一些模組才能開啟這個功能。

　　4.業務實踐-AML平臺訓練加速　　

　　在對火山引擎 AML 平臺的訓練加速實踐中，因為 GPU 機器型號較多，有的有本地盤，有的沒有，所以對於沒有本地盤的訓練場景，需要提供一些服務端加速儲存空間的支援；而對於有本地盤的機型，則需要把加速 GPU 機器上的本地盤進行接管。所以對於加速單元 DataNode，本質上是一個介於半托管和全託管之間的形態，很多時候是混合使用的場景。

　　所以我們在 CloudFS 服務端，構建了控制面和後設資料服務，也可以支援加速單元 DataNode。但是服務端的 DataNode 是按需建立的，如果本地 GPU 機器上的 ECS 有加速能力足夠的本地盤，那麼就不需要構建控制面和後設資料服務，如果它需要藉助服務端做一些快取能力的擴容，也可以對其進行實時擴容。加速單元 DataNode 透過 ENI 接入業務網路，所以整體的快取頻寬也不會有損耗。

　　5.業務實踐-資料湖多雲納管加速　　

　　在混合雲場景下的大資料業務實踐中，CloudFS 作為火山雲原生計算平臺的元件，會部署在客戶的私部機房。我們對其他雲廠商的物件桶做了適配，可以把遠端公有云物件桶上一些新的資料加速/預熱到這個私部的機房中。在此基礎上相關業務可以在私部機房內完成後續的大資料處理工作。　　

　　第一部分的測試工作中對 IO 打流進行了簡單的測試，結合快取功能以及 Page Cache 的關閉做了一些對比。如果沒有預熱，第一遍要從物件儲存讀，整體對於業務併發的需求就會更高。如果達到 256 的併發， 那它整個的 image/second 能夠做到 6000 多，這對於併發要求是非常高的。如果已經全部快取命中的情況下就只需要 32 個併發就可以達到 8800 的 image/second。當開啟了 Page Cache 或者是 FUSE 端的後設資料快取，這個資料結果可以做到更高。　　

　　第二部分的測試是基於這個資料集已經執行了一些簡單的基於學習訓練的任務負載後，與 Goofys 做了一個對比，無論是在 Epoch 快取是否命中的場景都會對效能有比較大的提升。只是因為第一個 Epoch 是從底層儲存上拿到的，所以效能提升不是很明顯，到快取全部命中之後就會有兩倍多的能力提升。

　　 04 未來規劃　　

　　未來的規劃主要包括三方面：

　　首先是繼續打磨 NAS 底座；

　　第二是實現更加細粒度的快取最佳化；

　　最後是快取的細粒度的彈性伸縮機制。