作者：之浩、展逸

企業(yè)在 Kubernetes 上運(yùn)行 AI、大數(shù)據(jù)應(yīng)用已成主流，資源彈性和開(kāi)發(fā)運(yùn)維效率得到顯著提升的同時(shí)，計(jì)算存儲(chǔ)分離架構(gòu)也帶來(lái)了挑戰(zhàn)：網(wǎng)絡(luò)延遲高、網(wǎng)絡(luò)費(fèi)用貴、存儲(chǔ)服務(wù)帶寬不足等。

以 AI 訓(xùn)練、基因計(jì)算、工業(yè)仿真等高性能計(jì)算場(chǎng)景為例，需要在短時(shí)間內(nèi)并發(fā)執(zhí)行海量計(jì)算，多計(jì)算實(shí)例共享訪問(wèn)文件系統(tǒng)的同一數(shù)據(jù)源。很多企業(yè)使用阿里云文件存儲(chǔ) NAS 或 CPFS 服務(wù)，掛載到阿里云容器服務(wù) ACK 運(yùn)行的計(jì)算任務(wù)上，實(shí)現(xiàn)數(shù)千臺(tái)計(jì)算節(jié)點(diǎn)的高性能共享訪問(wèn)。

然而，隨著算力規(guī)模和性能提升、以及模型規(guī)模和工作負(fù)載復(fù)雜度的增加，在云原生的機(jī)器學(xué)習(xí)和大數(shù)據(jù)場(chǎng)景下，高性能計(jì)算對(duì)并行文件系統(tǒng)的數(shù)據(jù)訪問(wèn)性能和靈活性要求也越來(lái)越高。

如何能更好地為容器化計(jì)算引擎提供彈性和極速的體驗(yàn)，成為了存儲(chǔ)的新挑戰(zhàn)。

為此，我們推出了彈性文件客戶端 EFC（Elastic File Client），基于阿里云文件存儲(chǔ)服務(wù)的高擴(kuò)展性、原生 POSIX 接口和高性能目錄樹(shù)結(jié)構(gòu)，打造云原生存儲(chǔ)系統(tǒng)。并且，EFC 與云原生數(shù)據(jù)編排和加速系統(tǒng) Fluid 結(jié)合，實(shí)現(xiàn)數(shù)據(jù)集的可見(jiàn)性、彈性伸縮、數(shù)據(jù)遷移、計(jì)算加速等，為云原生的 AI、大數(shù)據(jù)應(yīng)用共享訪問(wèn)文件存儲(chǔ)提供了可靠、高效、高性能的解決方案。

Fluid，云原生之?dāng)?shù)據(jù)新抽象

Fluid [ 1] 是一個(gè)云原生分布式數(shù)據(jù)編排和加速系統(tǒng)，主要面向數(shù)據(jù)密集型應(yīng)用（如大數(shù)據(jù)、AI等應(yīng)用）。

與傳統(tǒng)的面向存儲(chǔ)的PVC不同，F(xiàn)luid 從應(yīng)用角度出發(fā)，提出彈性數(shù)據(jù)集（Dataset）概念，對(duì)“在 Kubernetes 上使用數(shù)據(jù)的過(guò)程”進(jìn)行抽象。Fluid 是 Kubernetes 生態(tài)的開(kāi)源項(xiàng)目，由南京大學(xué)、阿里云以及 Alluxio 開(kāi)源社區(qū)聯(lián)合發(fā)起，已于 2021 年捐獻(xiàn)給 CNCF 社區(qū)。

Fluid 讓數(shù)據(jù)像流體一樣，在各種存儲(chǔ)源（如 NAS、CPFS、OSS 和 Ceph 等）和 Kubernetes 上層應(yīng)用之間來(lái)去自如，靈活高效地移動(dòng)、復(fù)制、驅(qū)逐、轉(zhuǎn)換和管理。

Fluid 可以實(shí)現(xiàn)數(shù)據(jù)集的 CRUD 操作、權(quán)限控制和訪問(wèn)加速等功能，用戶可以像訪問(wèn) Kubernetes 原生數(shù)據(jù)卷一樣直接訪問(wèn)抽象出來(lái)的數(shù)據(jù)。Fluid 當(dāng)前主要關(guān)注數(shù)據(jù)集編排和應(yīng)用編排這兩個(gè)重要場(chǎng)景：

• 在數(shù)據(jù)集編排方面，F(xiàn)luid 可以將指定數(shù)據(jù)集的數(shù)據(jù)緩存到指定特性的 Kubernetes 節(jié)點(diǎn)，以提高數(shù)據(jù)訪問(wèn)速度。

• 在應(yīng)用編排方面，F(xiàn)luid 可以將指定應(yīng)用調(diào)度到已經(jīng)存儲(chǔ)了指定數(shù)據(jù)集的節(jié)點(diǎn)上，以減少數(shù)據(jù)傳輸成本和提高計(jì)算效率。

兩者還可以組合協(xié)同編排，即協(xié)同考慮數(shù)據(jù)集和應(yīng)用需求進(jìn)行節(jié)點(diǎn)資源調(diào)度。

Fluid 為云原生 AI 與大數(shù)據(jù)應(yīng)用提供一層高效便捷的數(shù)據(jù)抽象，并圍繞抽象后的數(shù)據(jù)提供以下核心功能：

面向應(yīng)用的數(shù)據(jù)集統(tǒng)一抽象

數(shù)據(jù)集抽象不僅匯總來(lái)自多個(gè)存儲(chǔ)源的數(shù)據(jù)，還描述了數(shù)據(jù)的遷移性和特征，并提供可觀測(cè)性，例如數(shù)據(jù)集總數(shù)據(jù)量、當(dāng)前緩存空間大小以及緩存命中率。用戶可以根據(jù)這些信息評(píng)估是否需要擴(kuò)容或縮容緩存系統(tǒng)。

可擴(kuò)展的數(shù)據(jù)引擎插件

雖然 Dataset 是統(tǒng)一的抽象概念，但不同的存儲(chǔ)有不同的 Runtime 接口，實(shí)際的數(shù)據(jù)操作需要由不同的 Runtime 實(shí)現(xiàn)。Fluid 的 Runtime 分為兩類：CacheRuntime 實(shí)現(xiàn)緩存加速（包括開(kāi)源分布式緩存AlluxioRuntime、JuiceFSRuntime，阿里云 EFCRuntime、JindoRuntime 和騰訊云 GooseFSRuntime）；ThinRuntime 提供統(tǒng)一訪問(wèn)接口（如 s3fs、nfs-fuse 等分布式存儲(chǔ)系統(tǒng)），方便接入第三方存儲(chǔ)。

自動(dòng)化的數(shù)據(jù)操作

以 CRD 的方式提供數(shù)據(jù)預(yù)熱，數(shù)據(jù)遷移，數(shù)據(jù)備份等多種操作，并且支持一次性、定時(shí)和事件驅(qū)動(dòng)等多種模式，方便用戶結(jié)合到自身自動(dòng)化運(yùn)維體系中。

通用數(shù)據(jù)加速

將數(shù)據(jù)分布式緩存技術(shù)與自動(dòng)彈性（Autoscaling），可遷移（Portability），可觀測(cè)（Observability），親和性調(diào)度（Scheduling）等能力相結(jié)合，提升數(shù)據(jù)的訪問(wèn)性能。

運(yùn)行時(shí)平臺(tái)無(wú)關(guān)

支持原生、邊緣、Serverless、多集群等多種 Kubernetes 形態(tài)，可以運(yùn)行在公共云、邊緣、混合云等多樣化環(huán)境?？梢愿鶕?jù)環(huán)境差異選擇 CSI Plugin 或 sidecar 模式運(yùn)行存儲(chǔ)的客戶端。

EFC for 云原生存儲(chǔ)，彈性加速保障業(yè)務(wù)穩(wěn)定性

企業(yè)應(yīng)用在云原生現(xiàn)代化之后，可以構(gòu)建更多彈性的服務(wù)。相應(yīng)而來(lái)的問(wèn)題是，應(yīng)用數(shù)據(jù)的存儲(chǔ)如何同步實(shí)現(xiàn)云原生？

何為云原生存儲(chǔ)?

云原生存儲(chǔ)并不是在云上搭建的存儲(chǔ)系統(tǒng)，也不是部署在 K8S 容器中的存儲(chǔ)，而是可以完美的與 Kubernetes 環(huán)境融合，滿足業(yè)務(wù)彈性和敏捷性的存儲(chǔ)服務(wù)。

一個(gè)云原生存儲(chǔ)需要滿足以下要求：

1. 存儲(chǔ)服務(wù)穩(wěn)定性：系統(tǒng)各個(gè)節(jié)點(diǎn)的穩(wěn)定性、自恢復(fù)能力必須滿足需求。以文件存儲(chǔ)為例，原來(lái)一個(gè) NFS client 或者 FUSE 的 FO 只影響一臺(tái) ECS，而在云原生架構(gòu)中，單點(diǎn)存儲(chǔ)故障可能會(huì)影響一個(gè)容器集群中幾十個(gè) Pod。

2. 存儲(chǔ)容量和性能彈性：傳統(tǒng)分布式存儲(chǔ)的性能隨容量提升而提升，但是云原生環(huán)境中對(duì)存儲(chǔ)的性能需求其實(shí)是隨 Pod 的擴(kuò)縮容而快速變化。存儲(chǔ)系統(tǒng)需要在計(jì)算規(guī)?？焖偬嵘龝r(shí)，實(shí)現(xiàn)性能的彈性。

3. 支持計(jì)算 Pod 大規(guī)模伸縮：云原生應(yīng)用場(chǎng)景對(duì)服務(wù)的敏捷度、靈活性要求非常高，很多場(chǎng)景期望容器的快速啟動(dòng)、靈活的調(diào)度，1分鐘彈出 1000-2000 個(gè) Pod 都是家常便飯。這需要存儲(chǔ)卷也能敏捷地根據(jù) Pod 的變化而快速掛載。

4. 提供 Pod 粒度的可觀測(cè)性：多數(shù)存儲(chǔ)服務(wù)在文件系統(tǒng)級(jí)別提供了足夠的監(jiān)控能力，然后從云原生視角，提供 PV 和數(shù)據(jù)集視角的監(jiān)控?cái)?shù)據(jù)才能真正的幫助到云原生平臺(tái)管理者。

5. 存儲(chǔ)計(jì)算分離下提供接近本地存儲(chǔ)的性能：存儲(chǔ)計(jì)算分離帶來(lái)了彈性和敏捷，但是網(wǎng)絡(luò)延遲和遠(yuǎn)程訪問(wèn)協(xié)議的消耗也使得 Pod 訪問(wèn)存儲(chǔ)的 I/O 性能出現(xiàn)大幅下降。需要新的技術(shù)降低負(fù)面性能影響。

然而，以上需求都不是依靠存儲(chǔ)后端服務(wù)或客戶端可以獨(dú)立解決的。

因此，阿里云推出了彈性文件客戶端 —— EFC（Elastic File Client），結(jié)合阿里云文件存儲(chǔ)服務(wù)的高擴(kuò)展性，原生 POSIX 接口和高性能目錄樹(shù)結(jié)構(gòu)，打造云原生存儲(chǔ)系統(tǒng)。它替代 NAS 傳統(tǒng)的內(nèi)核態(tài) NFS 客戶端，提供多鏈接訪問(wèn)、元數(shù)據(jù)緩存、分布式數(shù)據(jù)緩存等加速能力，并提供端側(cè)性能監(jiān)控、QoS 能力，熱升級(jí)能力。

同時(shí)，EFC 規(guī)避了使用開(kāi)源 FUSE 的 POSIX 客戶端無(wú)法秒級(jí) Failover 的問(wèn)題，保障大規(guī)模計(jì)算時(shí)業(yè)務(wù)的穩(wěn)定性。

為數(shù)據(jù)密集應(yīng)用量身打造， EFCRuntime 核心能力一覽

EFCRuntime 是支撐 Dataset 訪問(wèn)加速能力的一種 Runtime 類型實(shí)現(xiàn)，其背后使用的緩存引擎為 EFC。Fluid 通過(guò)管理和調(diào)度 EFCRuntime 實(shí)現(xiàn)數(shù)據(jù)集的可見(jiàn)性、彈性伸縮、數(shù)據(jù)遷移、計(jì)算加速等。在 Fluid 上使用和部署 EFCRuntime 流程簡(jiǎn)單、兼容原生 Kubernetes 環(huán)境，并且能夠自動(dòng)可控地提升數(shù)據(jù)吞吐。

通過(guò) EFCRuntime 訪問(wèn)阿里云文件存儲(chǔ)，可以獲得文件存儲(chǔ)企業(yè)級(jí)基礎(chǔ)功能以外的如下能力：

1. POSIX 協(xié)議：EFC 提供標(biāo)準(zhǔn) POSIX 接口，結(jié)合文件存儲(chǔ) NAS 和 CPFS 服務(wù)，為容器應(yīng)用提供通過(guò) POSIX 接口訪問(wèn)共享數(shù)據(jù)的能力。

2. 秒級(jí) Failover：EFC 提供了秒級(jí) Failover 能力。當(dāng) FUSE 進(jìn)程由于各種原因 crash 或者進(jìn)行版本升級(jí)時(shí)，EFC 可以秒級(jí)自動(dòng)拉起，保障業(yè)務(wù) I/O 幾乎不受影響。

3. 強(qiáng)一致的語(yǔ)義：EFC 通過(guò)強(qiáng)一致的分布式 lease 機(jī)制實(shí)現(xiàn)文件和目錄的強(qiáng)一致：某 Pod 內(nèi)的文件寫入可以立刻被其他 Pod 讀??；新文件創(chuàng)建出來(lái)后，就可以立刻讓所有的其他客戶端同步訪問(wèn)到，讓用戶更方便地在多節(jié)點(diǎn)間管理數(shù)據(jù)。

4. 強(qiáng)大的端上緩存能力：EFC 優(yōu)化了 FUSE 的緩存邏輯，提供了更好的小文件讀寫性能，相比于傳統(tǒng)的 NFS 客戶端，性能提升 50% 以上。

5. 分布式緩存能力：EFC 內(nèi)含了阿里云自研的分布式緩存技術(shù)，將多個(gè)節(jié)點(diǎn)的內(nèi)存組合成超大緩存池，計(jì)算所需的熱數(shù)據(jù)無(wú)需每次從遠(yuǎn)端讀取，且吞吐和緩存池可以自然的隨著計(jì)算規(guī)模擴(kuò)大而擴(kuò)大。

6. 小文件預(yù)取能力：EFC 有針對(duì)性的預(yù)取熱目錄下的熱數(shù)據(jù)，節(jié)省拉取數(shù)據(jù)的開(kāi)銷。

訓(xùn)練耗時(shí)可縮短 87%，性能優(yōu)于開(kāi)源 NFS

我們使用 insightface(ms1m-ibug) 數(shù)據(jù)集 [ 2] 基于 Kubernetes 集群并使用 Arena [ 3] 在此數(shù)據(jù)集上驗(yàn)證并發(fā)讀取速度，基于 EFCRuntime 在開(kāi)啟本地緩存的情況下，性能大幅度優(yōu)于開(kāi)源 nfs，訓(xùn)練耗時(shí)縮短了 87%。（該測(cè)試場(chǎng)景會(huì)在后續(xù)相關(guān)文章中進(jìn)行詳細(xì)介紹）

如何快速上手使用 EFCRuntime ？

下面將以阿里云文件存儲(chǔ) NAS 為例，介紹如何快速使用 Fluid EFCRuntime加速 NAS 文件訪問(wèn)。

首先，您需要準(zhǔn)備好阿里云容器服務(wù) ACK Pro 版集群和阿里云 NAS 文件系統(tǒng)。

隨后，您只需要耗費(fèi) 5 分鐘左右時(shí)間，即可創(chuàng)建好需要的 EFCRuntime 環(huán)境，使用 EFCRuntime 的過(guò)程十分簡(jiǎn)單，您可以按照下面的流程進(jìn)行部署。

Step1：創(chuàng)建 Dataset 和 EFCRuntime

創(chuàng)建一個(gè) dataset.yaml 文件，文件中包含兩部分：

1. 首先包含 Dataset 自定義資源信息，Dataset 中聲明需要掛載的阿里云 NAS 文件系統(tǒng) URL（替換）以及 NAS 中的子路徑（替換 ）。

2. 接下來(lái)需要?jiǎng)?chuàng)建一個(gè) EFCRuntime，相當(dāng)于啟動(dòng)一個(gè) EFC 分布式集群來(lái)提供緩存服務(wù)。

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: efc-demo
spec:
  placement: Shared
  mounts:
    - mountPoint: "nfs://<nas_url>:<nas_dir>"
      name: efc
      path: "/"
---
apiVersion: data.fluid.io/v1alpha1
kind: EFCRuntime
metadata:
  name: efc-demo
spec:
  replicas: 3
  master:
    networkMode: ContainerNetwork
  worker:
    networkMode: ContainerNetwork
  fuse:
    networkMode: ContainerNetwork
  tieredstore:
    levels:
      - mediumtype: MEM
        path: /dev/shm
        quota: 15Gi

1. mountPoint：表示掛載的 NAS 或者 CPFS 文件系統(tǒng)路徑信息。例如：NAS 的格式為 nfs://:，CPFS 的格式為 cpfs://:；如果沒(méi)有子目錄要求可以使用根目錄。

具體使用，請(qǐng)參考文檔 [ 4] ：https://help.aliyun.com/document_detail/600930.html?spm=a2c4g.207353.0.0.431b113b6APACM

2. replicas：表示創(chuàng)建的分布式集群的緩存 Worker 數(shù)量，可根據(jù)計(jì)算節(jié)點(diǎn)內(nèi)存配置和數(shù)據(jù)集大小進(jìn)行調(diào)整。建議 quota 和 replicas 乘積大于所需緩存的數(shù)據(jù)集總大小。

3. network 可選值為 ContainerNetwork 和 HostNetwork。ACK 環(huán)境中建議選擇 ContainerNetwork，使用容器網(wǎng)絡(luò)不會(huì)有額外的性能損失。

4. mediumtype：表示緩存類型，只支持 HDD/SSD/MEM 中的其中一種緩存類型。其中 MEM 代表內(nèi)存，推薦使用 MEM。當(dāng)使用 MEM 時(shí)，path 所指定的緩存數(shù)據(jù)存儲(chǔ)目錄需為內(nèi)存文件系統(tǒng)（例如：tmpfs）

5. path：表示 EFC 緩存系統(tǒng) Worker 的緩存數(shù)據(jù)存儲(chǔ)目錄。建議保持 /dev/shm。

6. quota：表示單個(gè) Worker 組件提供的最大緩存容量?？筛鶕?jù)計(jì)算節(jié)點(diǎn)內(nèi)存配置和數(shù)據(jù)集大小進(jìn)行調(diào)整。建議 quota 和 replicas 乘積大于所需緩存的數(shù)據(jù)集總大小。

kubectl create -f dataset.yaml

查看Dataset的情況：

$ kubectl get dataset efc-demo

預(yù)期輸出為：

NAME       UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
efc-demo                                                                  Bound   24m

Step2：創(chuàng)建應(yīng)用容器體驗(yàn)加速效果

您可以通過(guò)創(chuàng)建應(yīng)用容器來(lái)使用 EFC 加速服務(wù)，或者進(jìn)行提交機(jī)器學(xué)習(xí)作業(yè)來(lái)進(jìn)行體驗(yàn)相關(guān)功能。

接下來(lái)，我們將創(chuàng)建兩個(gè)應(yīng)用容器來(lái)訪問(wèn)該數(shù)據(jù)集中的同一個(gè)大小為 10GB 的文件，您也可以使用別的文件來(lái)進(jìn)行測(cè)試，該文件需要預(yù)先存儲(chǔ)在 NAS 文件系統(tǒng)中。

定義如下 app.yaml 的文件：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: efc-app
  labels:
    app: nginx
spec:
  serviceName: nginx
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        command: ["/bin/bash"]
        args: ["-c", "sleep inf"]
        volumeMounts:
        - mountPath: "/data"
          name: data-vol
      volumes:
        - name: data-vol
          persistentVolumeClaim:
            claimName: efc-demo

執(zhí)行如下命令，查看待訪問(wèn)的數(shù)據(jù)文件大?。?/p>

kubectl exec -it efc-app-0 -- du -h /data/allzero-demo
10G     /data/allzero-demo

執(zhí)行如下命令，查看第一個(gè)應(yīng)用容器中文件的讀取時(shí)間（如果您使用自己的真實(shí)數(shù)據(jù)文件，請(qǐng)用真實(shí)文件路徑替代/data/allzero-demo）：

kubectl exec -it eac-app-0 -- bash -c "time cat /data/allzero-demo > /dev/null"

預(yù)期輸出為：

real    0m15.792s
user    0m0.023s
sys     0m2.404s

接著，再另一個(gè)容器中，測(cè)試讀取相同的 10G 大小文件的耗時(shí)如果您使用自己的真實(shí)數(shù)據(jù)文件，請(qǐng)用真實(shí)文件路徑替代 /data/allzero-demo）：

kubectl exec -it efc-app-1 -- bash -c "time cat /data/allzero-demo > /dev/null"

預(yù)期輸出：

real    0m9.970s
user    0m0.012s
sys     0m2.283s

從上述輸出信息，可發(fā)現(xiàn)吞吐量從原來(lái)的 648MiB/s 提高到了 1034.3MiB/s，對(duì)于相同文件的讀取效率提升了 59.5%。

總結(jié)和展望

通過(guò)將 Fluid 和 EFC 相結(jié)合，可以更好地為云原生場(chǎng)景下的 AI 和大數(shù)據(jù)服務(wù)提供支持。這種組合可以通過(guò)標(biāo)準(zhǔn)化的數(shù)據(jù)預(yù)熱和遷移等操作，提高數(shù)據(jù)使用效率并增強(qiáng)自動(dòng)化運(yùn)維的整合。

此外，我們還將支持 Serverless 場(chǎng)景下的運(yùn)行，從而為 Serverless 容器提供更好的分布式文件存儲(chǔ)訪問(wèn)體驗(yàn)。

最后，歡迎使用釘釘搜索群號(hào)加入我們，一起參與討論（釘釘群號(hào)：33214567）。

相關(guān)鏈接：

[1] Fluid

https://github.com/fluid-cloudnative/fluid

[2] insightface(ms1m-ibug) 數(shù)據(jù)集

https://github.com/deepinsight/insightface/tree/master/recognition/_datasets_#ms1m-ibug-85k-ids38m-images-56

[3] Arena

https://help.aliyun.com/document_detail/212117.html?spm=a2c4g.212116.0.0.47f66806YlI7y4

[4] EFC 加速 NAS 或 CPFS 文件訪問(wèn)

https://help.aliyun.com/document_detail/600930.html?spm=a2c4g.207353.0.0.431b113b6APACM文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-487185.html

到了這里，關(guān)于為數(shù)據(jù)彈性而生，阿里云云原生存儲(chǔ)再提速的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！