基於 ACK Fluid 的混合雲優化數據訪問(一):場景與架構

本系列文章將介紹如何基於 ACK Fluid 支持和優化混合雲的數據訪問場景。

概述

在 AI 和大數據時代,算力即正義,強大的算力推動了源源不斷的創新。然而,企業自建的算力集羣存在資源容量和彈性能力相對有限的問題,在業務低谷時可能會面臨高昂的資源閒置成本,而在業務高峯時則可能會面臨資源緊張的挑戰。特別是在 AI 和大數據時代,越來越多的企業正在尋求將公共雲作爲算力的有效補充。

考慮到某些企業對於數據主權的特殊要求,他們需要將數據存放在私有云中,但同時也希望能夠享受公共雲的彈性、可靠性和成本優勢。在這種情況下,混合雲的使用變得愈發普遍。混合雲可將阿里雲的雲服務與企業自建數據中心相融合,阿里雲上的計算資源通過專線訪問數據,並由 ACK One 統一進行管理。這種混合雲解決方案不僅幫助客戶節省成本,還提供了更高的性能和更強的安全保障。但是跨雲的計算訪問數據場景會帶來共性的問題:

  • 雲上通用計算和線下異構存儲的適配複雜:適配公共雲通用彈性計算訪問線下異構存儲需要一定的開發和集成工作,時間週期較長。生產環境的維護和問題排查成本也會有所增加。
  • 數據訪問性能影響工程效率:跨雲數據訪問慢影響數據分析和 AI 訓練的效率。
  • 冗餘數據訪問開銷:對於熱點數據的反覆讀取會帶來不必要流量費用。
  • 數據源的傳輸和複製 / 同步:如何複製 / 同步線下和公有云的數據,保證數據的一致性?

下面我們介紹一下 ACK Fluid[1]支持混合雲數據訪問常見的應用場景,這些場景以 Kubernetes 下讀數據爲主,特點是接入簡單,無侵入,性能好,低成本,自動化:

應用場景 1:

接入第三方分佈式存儲,連接彈性計算實例和雲下存儲

許多企業的數據都是存在線下,並且使用的存儲類型多樣,包括各種開源存儲(Ceph,lustrure,JuiceFS,CubeFS)和自建存儲。在使用公共雲計算資源的時候,也存在挑戰:

  • 數據遷雲安全性和成本評估時間長:對於數據遷移到雲存儲上,需要安全和存儲團隊的長時間評估,這會延緩整個上雲過程。
  • 數據訪問無法適配:比如公共雲對於彈性計算實例(ECI)支持的分佈式存儲類型有限(比如 NAS,OSS,CPFS),但是對於第三方存儲缺乏支持。
  • 接入雲平臺週期長和難度高:需要開發和維護雲原生兼容的 CSI 插件,一方面需要相關的專家和開發適配工程量,同時要維護版本的升級,同時支持的場景有限。比如自建 CSI 無法適配彈性計算實例(ECI)。
  • 缺乏可信透明的數據接入方式:如何在 Serverless 容器的黑盒系統訪問數據過程中規避泄露,如何確保數據在傳輸、訪問過程中安全,透明,可靠。
  • 避免業務修改的需求:如何確保業務用戶不感知基礎設施層面的差異,避免對現有應用本身進行任何修改。

ACK Fluid 通過提供 ThinRuntime 擴展機制[2]支持將基於 FUSE 實現第三方存儲客戶端以容器化的方式接入 Kubernetes 中,可以支持阿里雲上標準 Kubernetes,邊緣 Kubernetes,Serverless Kubernetes 多種形態。

1. 開發簡單

基於 ThinRuntime 方案,只需要會用 docker 即可,一般開發工作 2-3 小時左右,從而顯著降低了接入第三方存儲的工作成本。

2. 安全可控

以容器化的方式支持自定義方式實現數據訪問。整個數據訪問過程雲平臺無侵入,無需提供實現細節。

3. 使用方便

只需要在 PVC(持久卷申請)中添加特定 label 即可,滿足了業務用戶無需感知基礎設施層面的差異的需求,能將存儲適配時間縮短爲原計劃的十分之一。

4. 開源標準

基於開源 Fluid 標準對於 ThinRuntime 提供了完整的支持,只要滿足開源要求就可以適配 ACK Fluid。整個開發測試可以在 MiniKube 環境完成。

5. 可觀測可控制

第三方存儲客戶端只需要實現自身的容器化,就可以轉化爲 Fluid 管理的 Pod,無縫接入 Kubernetes 體系,並獲得可觀測性和計算資源可控制性。

總結:ACK Fluid 爲雲上計算訪問雲下數據提供了擴展性好,安全可控,低適配成本與雲平臺實現無關的好處,應用案例參見小米[3]

應用場景 2:

加速第三方存儲卷聲明,降低資源成本

在滿足場景 1 下,即便雲上計算能夠以 Kubernetes 的標準化協議 PV 存儲卷訪問企業的線下存儲,也無法避免在性能,成本上的挑戰和需求:

  • 數據訪問帶寬有限和高延時:雲上計算訪問雲下存儲帶來的數據訪問延時和帶寬有限,導致高性能計算耗時長,計算資源利用率低
  • 數據冗餘讀取,網絡費用昂貴:深度學習模型的超參調優、自動調參深度學習任務等運行期間會不斷重複訪問同一數據。但是由於 Kubernetes 原生調度器無法感知數據緩存狀態,導致應用調度的結果不佳,緩存無法重用,導致數據重複拉取引入更多外網和專線費用。
  • 線下分佈式存儲是數據併發訪問的瓶頸,而且面臨着性能和穩定性方面的挑戰:當大規模算力併發訪問線下存儲且深度學習訓練的 IO 壓力增大,線下分佈式存儲很容易成爲性能瓶頸。這會對計算任務造成影響,甚至會導致整個計算集羣失效。
  • 受網絡穩定性影響嚴重:一旦公共雲和數據中心之間網絡不夠穩定,會導致數據同步出錯,應用處於不可用的狀態。
  • 數據安全需求:元數據和數據需要保護,不允許夠持久化到雲盤上。

ACK Fluid 提供了基於 JindoRuntime 的 PV 存儲卷通用加速能力[4],可以支持滿足 PVC 的第三方存儲簡單,快速,安全的獲得通過分佈式緩存實現數據訪問加速能力,可以帶來如下好處:

1. 使用簡單

只需要實現 CSI 協議中 PVC 的第三方存儲即可以立即使用,無需額外開發。

2. 高性能,提效率

通過數據預熱、彈性帶寬和緩存親和感知調度,實現雲上計算集羣訪問雲下數據性能無損失

3. 降成本,省流量

通過分佈式緩存將熱點數據持久到雲上,減少數據讀取,降低網絡流量;同時吞吐可以彈性伸縮,按照業務削峯填谷。

4. 自動化

以數據爲中心的自動化運維,提高運維效率:包括自動緩存預熱、自動化擴縮容和清理,實現高效管理。

5. 更安全

分佈式內存緩存提高安全性:無需數據落盤,適用於敏感用戶,提供卓越性能和安全保障。

總結:ACK Fluid 爲雲上計算訪問第三方存儲 PVC 提供了開箱即用,高性能,低成本,自動化和無數據落盤的收益,應用案例參見 360。

應用場景 3:

實現第三方存儲主機目錄掛載 Kubernetes 化,標準化並加速提效

也有許多企業由於歷史原因和技術雲下存儲選擇沒有支持 CSI 協議,只支持以主機目錄的方式掛載,一方面存在與 Kubernetes 標準化平臺的對接的挑戰,另一方面也需要應對與場景 2 類似的性能和成本的問題:

  • 缺少標準化,上雲困難:主機目錄掛載的模式由於無法被 Kubernetes 感知和調度,很難被容器化工作負載使用和管理。
  • 缺少數據隔離性:由於整個目錄都被掛載到主機上,並被所有的工作負載訪問,導致數據全局可見。
  • 數據訪問在成本,性能和可用性上有何場景 2 相同的需求,因此不再贅述。

ACK Fluid 提供了基於 JindoRuntime 的 PV 主機目錄通用加速能力,直接支持主機目錄掛載可以原生,簡單,快速,安全的獲得通過分佈式緩存實現數據訪問加速能力。

1. 標準化

將傳統架構遷移至雲原生:將主機目錄掛載模式變化爲 Kubernetes 可以管理的 CSI 協議下的 PV 存儲卷,便捷與公共雲標準協議結合。

2. 遷移低成本

傳統架構遷移低成本:無需額外開發,只需要在部署時刻將 Hostpath 協議轉換成 PV 存儲卷。

3. 數據隔離更容易

接入 Fluid 後,可以通過子數據集模式可以控制不同用戶對於線下存儲不同目錄的可見性,無需額外開發。

4. 高性能,提效率

通過數據預熱、彈性帶寬和緩存親和感知調度,實現雲上計算集羣訪問雲下數據性能無損失。

5. 降成本,省流量

通過分佈式緩存將熱點數據持久到雲上,減少數據讀取,降低網絡流量;同時吞吐可以彈性伸縮,按照業務削峯填谷。

6. 自動化

以數據爲中心的自動化運維,提高運維效率:包括自動緩存預熱、自動化擴縮容和清理,實現高效管理。

7. 更安全

分佈式內存緩存提高安全性:無需數據落盤,適用於敏感用戶,提供卓越性能和安全保障。

總結:ACK Fluid 爲雲上計算訪問第三方存儲的主機目錄掛載方式提供了開箱即用,高性能,低成本,自動化和無數據落盤的收益。

應用場景 4:

跨區域中心數據分發

許多企業出於性能、安全、穩定性和資源隔離的目的,會在不同區域建立多個計算集羣。而這些計算集羣需要遠程訪問唯一中心化的數據存儲。比如隨着大語言模型的逐漸成熟,基於其的多區域推理服務也逐漸成爲各個企業需要支持的能力,針對這一場景,仍有不小的挑戰:

  • 多計算集羣間手動同步數據非常耗時。
  • 大型語言模型的管理複雜,由於不同業務需求會選擇不同基礎模型和數據,導致最終模型存在差異。
  • 模型數據頻繁更新,根據不同業務輸入進行迭代。
  • 拉取大型語言模型文件耗時長,啓動模型推理服務較慢。參數規模龐大,體積通常達到幾百 GB,在 GPU 顯存中加載時間巨大。
  • 模型更新要求所有區域同步更新,使用過載的存儲集羣進行復製作業會嚴重影響現有負載性能。

ACK Fluid 除了提供通用存儲客戶端的加速能力,還提供了定時和觸發式數據遷移和預熱能力,簡化數據分發的複雜度。

1. 節省成本

跨區流量成本大幅降低,計算時間明顯縮短,少量增加計算集羣成本;並且可以通過彈性進一步優化。

2. 加速應用

由於計算的數據訪問在同一個數據中心或者可用區內完成通信,延時降低,且緩存吞吐併發能力可線性擴展。

3. 簡化數據同步

通過自定義策略控制數據同步操作,降低數據訪問爭搶,同時通過自動化的方式降低運維複雜度。

綜述

在本文中,我們簡單介紹了通過 ACK Fluid 和 JindoFS 團隊的 JindoRuntime 可以支持的混合雲場景分類,後續文章中,我們會對以上場景的具體實踐和使用方式進行詳細介紹。

相關鏈接:

[1] ACK Fluid

https://help.aliyun.com/zh/ack/cloud-native-ai-suite/user-guide/overview-of-fluid

[2] ThinRuntime 擴展機制

https://github.com/fluid-cloudnative/fluid/blob/master/docs/zh/samples/thinruntime.md

[3] 小米

https://www.infoq.cn/article/kco7hi5TcVE08ySwNIw7

[4] PV 存儲卷通用加速能力

https://help.aliyun.com/zh/ack/cloud-native-ai-suite/user-guide/accelerate-pv-storage-volume-data-access

作者:車漾(必嘫)

點擊立即免費試用雲產品 開啓雲上實踐之旅!

原文鏈接

本文爲阿里雲原創內容,未經允許不得轉載。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章