Fluid + GooseFS 助力雲原生資料編排與加速快速落地

騰訊雲原生發表於2021-08-17
UIGo

前言

Fluid 作為基於 Kubernetes 開發的面向雲原生存算分離場景下的資料排程和編排加速框架，已於近期完成了 v0.6.0 版本的正式釋出。騰訊雲容器 TKE 團隊一直致力於參與 Fluid 社群建設，在最新版本中貢獻了以下兩大特性：快取引擎高可用執行時、新增資料快取引擎實現 GooseFSRuntime 。

什麼是存算分離？雲原生背景下為什麼需要資料編排？Fluid 和 GooseFSRuntime 又是什麼？別擔心！針對這些問題，我們帶你一一探索。本文將首先介紹 Fluid 技術的誕生背景以及與 GooseFS 之間的關係；其次通過在 TKE 叢集上的實際操練讓大家體驗 Fluid v0.6.0 的兩大特性；最後我們將和大家一起探討 Fluid 社群的未來發展。希望通過這篇文章能讓大家進一步瞭解雲原生應用場景下的資料編排能力，期待有興趣的你一起參與 Fluid 的社群建設。

現狀和挑戰

什麼是存算分離架構？

“存算分離”是當前網路技術發展和社會經濟進步的時代產物，是最適合當前時代發展需求的一種架構。公有云環境為了滿足使用者按需服務、無限擴充的需求，常使用塊儲存、檔案儲存和物件儲存來取代本地儲存，例如在建立 TKE 叢集時，會根據單盤的最大吞吐量、IOPS 等指標選擇掛載高效能雲硬碟、SSD 或增強型 SSD。這些不同規格的儲存載體本質上都是雲硬碟，且需要不定量地消耗網路頻寬。但是隨著雲廠商在技術上的不斷推動，以及使用者對成本、擴充套件性以及效能的極致追求，計算和儲存分離已然成為了雲原生架構的發展趨勢。

CNCF 釋出的 《2020年中國雲原生報告》 指出，容器應用相對於兩年前達到了 240% 的驚人增長，容器編排實施標準 Kubernetes 在生產中的比例也從 72% 上升到 82%。Kubernetes 作為雲原生時代的底座，憑藉便捷的可移植性、豐富的可擴充套件性以及編排排程的自動化能力，已然成為公有云、私有云還有混合雲的首選。而目前很多 AI 和大資料的業務也在積極的向 Kubernetes 靠攏，例如開源機器學習平臺 Kubeflow；大資料計算框架 Spark 也推出 Spark-operator 以滿足基於 Kubernetes 構建大資料計算平臺的需求。雲原生應用向儲存計算分離架構演進的趨勢日益增長。

雲原生存算分離架構面臨的挑戰？

從 Adrian Cockcroft 於2013年介紹 Netflix 在 AWS 上基於 Cloud Native 的成功應用，到2015年 Pivotal 的 Matt Stine 定義雲原生架構以及雲原生計算基金會 CNCF 的成立，雲原生價值已經得到了企業使用者的廣泛接受。雖然雲原生正在加速向垂直行業的滲透，但存算分離的公有云場景仍然讓雲原生業務的發展面臨著諸多挑戰：

  • 雲平臺存算分離架構導致資料訪問延時高。隨著高速網路裝置和負載的大規模使用，所有的資料都依賴網路 IO 到計算節點計算和彙總，尤其是資料密集型應用，大概率網路會成為瓶頸（沒有銀彈）。IO 的瓶頸最終會導致計算和儲存的資源無法充分的利用，將會背離利用雲來實現降本增效的初衷。
  • 混合雲場景下跨儲存系統的聯合分析困難。大多數公司的業務線可能會分為不同的小組，不同的小組針對不同的 Workload 使用的計算框架也各有不同，而框架支援的儲存也各有特點。例如 HDFS 針對大資料領域、Lustre 針對超算領域等等。當需要聯合資料進行綜合性分析時，資料副本數增加、資料轉換的成本增加，都必然導致資源（即人力）的成本增高、業務迭代的效率降低等風險。
  • 雲中資料安全治理與多維度管理日趨複雜。資料是很多公司的生命線，資料洩露、誤操作、生命週期管理不當都會造成巨大損失。如何在雲原生環境中保障資料隔離，保護好使用者的資料生命週期，都存在較大挑戰。

Fluid 能做什麼？


Fluid 類似雲原生世界的“物流管理系統”，物流的發出方是各種資料來源，例如 COS、HDFS、Ceph 以及 Lustre 等；此外，還要有具備儲存不同貨物（即聚合不同資料來源）能力的物流倉庫，如 GooseFS；而物流的收貨地址就是使用者期望資料被使用的計算節點。

Fluid 的設計目標就是為了將貨物（資料）高效、準確的投放到使用者手中。在實際生活中，我們常以快遞櫃的形式進行快遞的分發，即在貨物到達指定快遞櫃後希望使用者主動領取快遞。這樣可以避免快遞積壓，使用者也可以彈性規劃快遞的領取時間。其實設計理念體現到雲端計算場景就類似運算元下推，將更多的計算下推到儲存層完成，減少所需傳輸的資料量。希望在最後一公里實現，“移動計算到儲存”而不是“移動儲存到計算”。

GooseFS & Fluid 探究

雲原生資料湖加速器 GooseFS

資料湖加速器（Data Lake Accelerator Goose FileSystem，GooseFS），是由騰訊雲推出的高可靠、高可用、彈性的資料湖加速服務。依靠物件儲存（Cloud Object Storage，COS）作為資料湖儲存底座的成本優勢，為資料湖生態中的計算應用提供統一的資料湖入口，加速海量資料分析、機器學習、人工智慧等業務訪問儲存的效能；採用了分散式叢集架構，具備彈性、高可靠、高可用等特性，為上層計算應用提供統一的名稱空間和訪問協議，方便使用者在不同的儲存系統管理和流轉資料。

分散式資料編排和加速框架 Fluid

Fluid 是 CNCF Sandbox 開源的分散式資料編排和加速框架，是學術界（南京大學等）原創研究和工業界落地實踐的結合開源專案。在計算和儲存分離的大背景驅動下，Fluid 的目標是為 AI 與大資料雲原生應用提供一層高效便捷的資料抽象，將資料從儲存抽象出來，以便達到：

  • 通過資料親和性排程和分散式快取引擎加速，實現資料和計算之間的融合，從而加速計算對資料的訪問；
  • 將資料獨立於儲存進行管理，並且通過 Kubernetes 的名稱空間進行資源隔離，實現資料的安全隔離；
  • 將來自不同儲存的資料聯合起來進行運算，從而有機會打破不同儲存的差異性帶來的資料孤島效應。

從使用者角度來說，使用者宣告資料來源後，Fluid 將自動排程資料到最合適的節點，並向外暴露 kubernetes 原生持久化資料卷。使用者應用例如大資料應用 hadoop、spark 或 AI 應用 Pytorch、Tensorflow 等只需要掛載資料卷，Fluid 就可以通過親和性排程讓應用達到資料加速和統一訪問的目的。Fluid 專案開源短短半年多時間內發展迅速，吸引了眾多大廠的專家和工程師的關注與貢獻，專案 Adoptor 包括騰訊、微博、奇虎 360、中國電信、BOSS 直聘、第四正規化等多家大型知名 IT 和網際網路企業。

理清 TKE、Fluid 和 GooseFS 之間的關係

Fluid 與騰訊雲 TKE 融合的架構如下所示，根據不同的檢視分為計算排程層、儲存層以及任務層，下面我們將對該架構剝繭抽絲，帶你快速理清 Fluid、TKE、GooseFS 三者之間的關係。

  1. 計算排程層：TKE 以 Kubernetes 環境為底座提供了容器應用的部署平臺，Fluid GooseFS 控制器將控制 GooseFS 例項中的 Master Pod、Worker Pod 以及 Fuse Pod 建立在最合適的 TKE Worker 節點。
  2. 儲存層：控制器會根據使用者指定的資料來源將底層儲存例如 COS、HDFS 的資料快取到 Worker Pod 中。
  3. 任務層：任務 pod 指定持久化儲存卷，控制器 webhook 會注入親和性資訊，以實現將使用快取任務優先排程到有快取節點以及將不使用快取任務先排程到沒有快取節點的目標。

總體來說，Fluid 通過雲原生的架構，在資料最後一公里，通過“移動計算到儲存”的理念解決了 AI/大資料 存算分離場景下的諸多痛點。

Fluid v0.6.0 特性體驗

以下特性均由騰訊雲 TKE 團隊設計貢獻

“快取引擎高可用執行時”

在 GooseFS 分散式快取檔案系統中，高可用性包含兩層，一是整個檔案系統的可用性，二是資料的完整和一致性。Master 作為全域性後設資料管理元件，通過 Master High-Availability 保證檔案系統的高可用；通過 Raft 演算法實現選主、狀態機同步等操作保證日誌和後設資料的完整和一致性。在真實業務場景下如果單個 master 出現故障，會直接影響業務的正常執行，這就要求 Fluid 需要支援快取引擎多 master 來保證容錯率。

“新增資料快取引擎實現 GooseFSRuntime”

為了支援騰訊雲 TKE 上的計算任務對快取系統的需求，我們在新版本中新增了一種支撐 Fluid Dataset 資料管理和快取的執行引擎實現。使用者可以在 Fluid 中通過 GooseFSRuntime 使用 GooseFS 快取能力進行騰訊雲 COS 檔案的訪問和快取。在 Fluid 上使用和部署 GooseFSRuntime 流程簡單、相容原生 K8s 環境、開箱即用，配合騰訊雲 TKE 食用更佳。

特性 Demo

本文件將向你簡單地展示上述特性

前提條件

在執行該示例之前，請參考安裝文件完成安裝，並檢查 Fluid 各元件正常執行：

$ kubectl get pod -n fluid-system
goosefsruntime-controller-5b64fdbbb-84pc6   1/1     Running   0          8h
csi-nodeplugin-fluid-fwgjh                  2/2     Running   0          8h
csi-nodeplugin-fluid-ll8bq                  2/2     Running   0          8h
csi-nodeplugin-fluid-dhz7d                  2/2     Running   0          8h
dataset-controller-5b7848dbbb-n44dj         1/1     Running   0          8h

通常來說，你會看到一個名為dataset-controller的 pod、一個名為 goosefsruntime-controller 的 pod 和多個名為csi-nodeplugin的 pod 正在執行。其中，csi-nodeplugin這些 pod 的數量取決於你的 Kubernetes 叢集中結點的數量。

新建工作環境

$ mkdir <any-path>/demo
$ cd <any-path>/demo

檢視全部節點

$ kubectl get nodes
NAME            STATUS   ROLES    AGE     VERSION
192.168.1.145   Ready    <none>   7d14h   v1.18.4-tke.13
192.168.1.146   Ready    <none>   7d14h   v1.18.4-tke.13
192.168.1.147   Ready    <none>   7d14h   v1.18.4-tke.13

建立 Dataset 資源

cat >> dataset.yaml <<EOF
apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: hbase
spec:
  mounts:
    - mountPoint: https://mirrors.tuna.tsinghua.edu.cn/apache/hbase/stable/
      name: hbase
EOF
$ kubectl create -f dataset.yaml
dataset.data.fluid.io/hbase created

mountPoint 這裡為了方便使用者進行實驗使用的是 Web UFS, 使用 COS 作為 UFS 可見 加速 COS。

建立並檢視 GooseFSRuntime 資源

cat >> runtime.yaml <<EOF
apiVersion: data.fluid.io/v1alpha1
kind: GooseFSRuntime
metadata:
  name: hbase
spec:
  replicas: 3
  tieredstore:
    levels:
      - mediumtype: MEM
        path: /dev/shm
        quota: 2G
        high: "0.8"
        low: "0.7"
  master:
    replicas: 3
EOF
$ kubectl create -f runtime.yaml
goosefsruntime.data.fluid.io/hbase created
$ kubectl get pod
NAME                 READY   STATUS    RESTARTS   AGE
hbase-fuse-4v9mq     1/1     Running   0          84s
hbase-fuse-5kjbj     1/1     Running   0          84s
hbase-fuse-tp2q2     1/1     Running   0          84s
hbase-master-0       1/1     Running   0          104s
hbase-master-1       1/1     Running   0          102s
hbase-master-2       1/1     Running   0          100s
hbase-worker-cx8x7   1/1     Running   0          84s
hbase-worker-fjsr6   1/1     Running   0          84s
hbase-worker-fvpgc   1/1     Running   0          84s
$ kubectl get pvc
NAME    STATUS   VOLUME          CAPACITY   ACCESS MODES   STORAGECLASS   AGE
hbase   Bound    default-hbase   100Gi      ROX            fluid          12h
$ kubectl get goosefsruntime
NAME     MASTER PHASE   WORKER PHASE   FUSE PHASE   AGE
hbase   Ready           Ready            Ready     15m
$ kubectl exec -ti hbase-master-0 bash
# 可以看到其中一個節點是 LEADER 其餘兩個是 FOLLOWER 
$ goosefs fs masterInfo
current leader master: hbase-master-0:26000
All masters: [hbase-master-0:26000, hbase-master-1:26000, hbase-master-2:26000]

我們這裡主要關注三個地方：

  1. 到這裡，我們已經建立了可以供計算任務訪問的分散式快取引擎 GooseFS，計算任務的 pod 只需要指定 persistentVolumeClaim.name 為 hbase 即可獲取快取加速的能力。
  2. 同時只需要通過指定 spec.master.replicas=n ，這裡 n 為大於等於 3 的奇數，就可以直接開啟 Master HA 模式。
  3. 只需要指定 spec.replicas=n，控制器將為 GooseFS 快取系統建立 3 個 worker pod 以及 3 fuse pod

資料預熱和加速

// 不使用快取情況下任務時間
$ cat >> nginx.yaml <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - mountPath: /data
          name: hbase-vol
  volumes:
    - name: hbase-vol
      persistentVolumeClaim:
        claimName: hbase # 掛載 pvc claimName 和 dataset 一致
EOF
$ kubectl create -f nginx.yaml
$ kubectl exec -it nginx /bin/bash
$ root@nginx:/# time cp -r /data/hbase /
real    1m9.031s
user    0m0.000s
sys    0m2.101s
$ kubectl delete -f nginx.yaml
// 使用快取加速
// 建立 Dataload 資源
$ cat >> dataload.yaml <<EOF
apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
  name: hbase-dataload
spec:
  dataset:
    name: hbase
    namespace: default
  target:
    - path: /
      replicas: 1
EOF
$ kubectl create -f dataload.yaml
// 檢視快取預熱進度
$ kubectl get dataset hbase --watch 
NAME    UFS TOTAL SIZE   CACHED      CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
hbase   545.32MiB        545.32MiB   5.59GiB          100.0%              Bound   16m
$ kubectl create -f nginx.yaml
$ kubectl exec -it nginx /bin/bash
$ root@nginx:/# time cp -r /data/hbase /
real    0m0.278s
user    0m0.000s
sys    0m0.273s

這種大幅度的加速效果(1m9s -> 0.278s 加速248倍) 歸因於 GooseFS 所提供的強大的快取能力。總結下來，通過 GooseFSRuntime 將使用者定義的資料來源統一管理，通過快取來加速應用的訪問。

這裡主要展示 v0.6.0 的兩大功能：快取引擎高可用執行時以及新增資料快取引擎實現 GooseFSRuntime ，不涉及 Fluid 其他功能，其他功能可見 使用文件。

Fluid Roadmap

上圖為 Fluid 社群現規劃的 Roadmap, 主要分為六個方面：自動化運維和可觀測性、多執行時支援、資料彈性伸縮、編排排程優化、Fluid Agent 以及接入模式。目前自動化運維、多執行時支援以及接入模式基本實現，後期社群主要關注以下三個方面：

  1. 彈性擴充方面，目前已經支援基於自定義指標對快取 Worker 進行 HPA(Horizontal Pod Autoscaler) 以及針對業務波峰波谷的 CronHPA 。但是由於快取引擎資料再平衡（re-balance）功能的缺失，目前無法利用擴縮容達到降本增效的目的，這個也是社群後期重點關注的特性。
  2. Fluid Agent 方面，通過 agent push 模式，上報一些關鍵的運維指標例如是否有殘留需要清理、節點是否有快取等；同時不同節點上的系統資訊例如 cpu/memory 使用量、磁碟使用量、page cache 使用資訊等，通過這些資訊可以指導 fluid 排程器對資料集進行最優排程。
  3. 排程策略方面，目前主要涉及三個方面的排程：
    1. 資料集排程：目前已經適配 kubernetes 排程，例如 Toleration、Node Selector、Preferred 排程；後期我們希望以 Scheduling Framework 的方式通過 Filter、Scoring、Binding 等操作實現資料集最優排程。
    2. 任務排程：目前已經可以通過 webhook 自動對指定 namespace 下的負載加入親和性和反親和性標籤進行任務排程；
    3. 任務排程和資料預熱協同排程：通過排程資訊對 Job Queue 中 Job 使用的資料進行預載入，達到流水線優化的目的。

總結與展望

本文首先介紹了 Fluid 技術的誕生背景以及資料編排功能如何在存算分離場景下解決雲原生業務對"移動計算到儲存”的需求痛點；其次通過簡要分析 Fluid 的架構，理清了 Fluid、GooseFS、TKE 三者的關係，並通過簡單的 Demo 展示了 v0.6.0 的兩大基礎功能；最後通過 Fluid Roadmap 總結了目前社群已經完成的工作以及未來的發展規劃。

總的來說，在公有云實現計算和儲存的極致彈性才是增效降本的前提。只有讓我們的業務更好的使用彈性的能力，獲取雲原生乃至雲端計算最大的紅利，才能讓應用生於雲、長於雲。

相關文章