关于云原生:为数据弹性而生阿里云云原生存储再提速

企业在 Kubernetes 上运行 AI、大数据利用已成支流，资源弹性和开发运维效率失去显著晋升的同时，计算存储拆散架构也带来了挑战：网络提早高、网络费用贵、存储服务带宽有余等。

以 AI 训练、基因计算、工业仿真等高性能计算场景为例，须要在短时间内并发执行海量计算，多计算实例共享拜访文件系统的同一数据源。很多企业应用阿里云文件存储 NAS 或 CPFS 服务，挂载到阿里云容器服务 ACK 运行的计算工作上，实现数千台计算节点的高性能共享拜访。

然而，随着算力规模和性能晋升、以及模型规模和工作负载复杂度的减少，在云原生的机器学习和大数据场景下，高性能计算对并行文件系统的数据拜访性能和灵活性要求也越来越高。

如何能更好地为容器化计算引擎提供弹性和极速的体验，成为了存储的新挑战。

为此，咱们推出了弹性文件客户端 EFC（Elastic File Client），基于阿里云文件存储服务的高扩展性、原生 POSIX 接口和高性能目录树结构，打造云原生存储系统。并且，EFC 与云原生数据编排和减速零碎 Fluid 联合，实现数据集的可见性、弹性伸缩、数据迁徙、计算减速等，为云原生的 AI、大数据利用共享拜访文件存储提供了牢靠、高效、高性能的解决方案。

Fluid[1]是一个云原生分布式数据编排和减速零碎，次要面向数据密集型利用（如大数据、AI 等利用）。

与传统的面向存储的 PVC 不同，Fluid 从利用角度登程，提出弹性数据集（Dataset）概念，对“在 Kubernetes 上应用数据的过程”进行形象。Fluid 是 Kubernetes 生态的开源我的项目，由南京大学、阿里云以及 Alluxio 开源社区联结发动，已于 2021 年募捐给 CNCF 社区。

Fluid 让数据像流体一样，在各种存储源（如 NAS、CPFS、OSS 和 Ceph 等）和 Kubernetes 下层利用之间来去自如，灵便高效地挪动、复制、驱赶、转换和治理。

Fluid 能够实现数据集的 CRUD 操作、权限管制和拜访减速等性能，用户能够像拜访 Kubernetes 原生数据卷一样间接拜访形象进去的数据。Fluid 以后次要关注数据集编排和利用编排这两个重要场景：

在数据集编排方面，Fluid 能够将指定数据集的数据缓存到指定个性的 Kubernetes 节点，以进步数据访问速度。
在利用编排方面，Fluid 能够将指定利用调度到曾经存储了指定数据集的节点上，以缩小数据传输老本和进步计算效率。

两者还能够组合协同编排，即协同思考数据集和利用需要进行节点资源调度。

Fluid 为云原生 AI 与大数据利用提供一层高效便捷的数据抽象，并围绕形象后的数据提供以下外围性能：

面向利用的数据集对立形象

数据集形象不仅汇总来自多个存储源的数据，还形容了数据的迁移性和特色，并提供可观测性，例如数据集总数据量、以后缓存空间大小以及缓存命中率。用户能够依据这些信息评估是否须要扩容或缩容缓存零碎。

可扩大的数据引擎插件

尽管 Dataset 是对立的抽象概念，但不同的存储有不同的 Runtime 接口，理论的数据操作须要由不同的 Runtime 实现。Fluid 的 Runtime 分为两类：CacheRuntime 实现缓存减速（包含开源分布式缓存 AlluxioRuntime、JuiceFSRuntime，阿里云 EFCRuntime、JindoRuntime 和腾讯云 GooseFSRuntime）；ThinRuntime 提供对立拜访接口（如 s3fs、nfs-fuse 等分布式存储系统），不便接入第三方存储。

自动化的数据操作

以 CRD 的形式提供数据预热，数据迁徙，数据备份等多种操作，并且反对一次性、定时和事件驱动等多种模式，不便用户联合到本身自动化运维体系中。

通用数据减速

将数据分布式缓存技术与主动弹性（Autoscaling），可迁徙（Portability），可观测（Observability），亲和性调度（Scheduling）等能力相结合，晋升数据的拜访性能。

运行时平台无关

反对原生、边缘、Serverless、多集群等多种 Kubernetes 状态，能够运行在公共云、边缘、混合云等多样化环境。能够依据环境差别抉择 CSI Plugin 或 sidecar 模式运行存储的客户端。

企业应用在云原生现代化之后，能够构建更多弹性的服务。相应而来的问题是，利用数据的存储如何同步实现云原生？

何为云原生存储?

云原生存储并不是在云上搭建的存储系统，也不是部署在 K8S 容器中的存储，而是能够完满的与 Kubernetes 环境交融，满足业务弹性和敏捷性的存储服务。

一个云原生存储须要满足以下要求：

存储服务稳定性：零碎各个节点的稳定性、自恢复能力必须满足需要。以文件存储为例，原来一个 NFS client 或者 FUSE 的 FO 只影响一台 ECS，而在云原生架构中，单点存储故障可能会影响一个容器集群中几十个 Pod。
存储容量和性能弹性：传统分布式存储的性能随容量晋升而晋升，然而云原生环境中对存储的性能需求其实是随 Pod 的扩缩容而疾速变动。存储系统须要在计算规模疾速晋升时，实现性能的弹性。
反对计算 Pod 大规模伸缩：云原生利用场景对服务的麻利度、灵活性要求十分高，很多场景冀望容器的疾速启动、灵便的调度，1 分钟弹出 1000-2000 个 Pod 都是粗茶淡饭。这须要存储卷也能敏捷地依据 Pod 的变动而疾速挂载。
提供 Pod 粒度的可观测性：少数存储服务在文件系统级别提供了足够的监控能力，而后从云原生视角，提供 PV 和数据集视角的监控数据能力真正的帮忙到云原生平台管理者。
存储计算拆散下提供靠近本地存储的性能：存储计算拆散带来了弹性和麻利，然而网络提早和近程拜访协定的耗费也使得 Pod 拜访存储的 I/O 性能呈现大幅降落。须要新的技术升高负面性能影响。

然而，以上需要都不是依附存储后端服务或客户端能够独立解决的。

因而，阿里云推出了弹性文件客户端 —— EFC（Elastic File Client），联合阿里云文件存储服务的高扩展性，原生 POSIX 接口和高性能目录树结构，打造云原生存储系统。它代替 NAS 传统的内核态 NFS 客户端，提供多链接拜访、元数据缓存、分布式数据缓存等减速能力，并提供端侧性能监控、QoS 能力，热降级能力。

同时，EFC 躲避了应用开源 FUSE 的 POSIX 客户端无奈秒级 Failover 的问题，保障大规模计算时业务的稳定性。

EFCRuntime 是撑持 Dataset 拜访减速能力的一种 Runtime 类型实现，其背地应用的缓存引擎为 EFC。Fluid 通过治理和调度 EFCRuntime 实现数据集的可见性、弹性伸缩、数据迁徙、计算减速等。在 Fluid 上应用和部署 EFCRuntime 流程简略、兼容原生 Kubernetes 环境，并且可能主动可控地晋升数据吞吐。

通过 EFCRuntime 拜访阿里云文件存储，能够取得文件存储企业级根底性能以外的如下能力：

POSIX 协定：EFC 提供规范 POSIX 接口，联合文件存储 NAS 和 CPFS 服务，为容器利用提供通过 POSIX 接口访问共享数据的能力。
秒级 Failover：EFC 提供了秒级 Failover 能力。当 FUSE 过程因为各种起因 crash 或者进行版本升级时，EFC 能够秒级主动拉起，保障业务 I/O 简直不受影响。
强统一的语义：EFC 通过强统一的分布式 lease 机制实现文件和目录的强统一：某 Pod 内的文件写入能够立即被其余 Pod 读取；新文件创建进去后，就能够立即让所有的其余客户端同步拜访到，让用户更不便地在多节点间治理数据。
弱小的端上缓存能力：EFC 优化了 FUSE 的缓存逻辑，提供了更好的小文件读写性能，相比于传统的 NFS 客户端，性能晋升 50% 以上。
分布式缓存能力：EFC 内含了阿里云自研的分布式缓存技术，将多个节点的内存组合成超大缓存池，计算所需的热数据无需每次从远端读取，且吞吐和缓存池能够天然的随着计算规模扩充而扩充。
小文件预取能力：EFC 有针对性的预取热目录下的热数据，节俭拉取数据的开销。

咱们应用 insightface(ms1m-ibug) 数据集 [2] 基于 Kubernetes 集群并应用 Arena[3]在此数据集上验证并发读取速度，基于 EFCRuntime 在开启本地缓存的状况下，性能大幅度优于开源 nfs，训练耗时缩短了 87%。（该测试场景会在后续相干文章中进行具体介绍）

上面将以阿里云文件存储 NAS 为例，介绍如何疾速应用 Fluid EFCRuntime 减速 NAS 文件拜访。

首先，您须要筹备好阿里云容器服务 ACK Pro 版集群和阿里云 NAS 文件系统。

随后，您只须要消耗 5 分钟左右工夫，即可创立好须要的 EFCRuntime 环境，应用 EFCRuntime 的过程非常简略，您能够依照上面的流程进行部署。

创立一个 dataset.yaml 文件，文件中蕴含两局部：

首先蕴含 Dataset 自定义资源信息，Dataset 中申明须要挂载的阿里云 NAS 文件系统 URL（替换）以及 NAS 中的子门路（替换）。
接下来须要创立一个 EFCRuntime，相当于启动一个 EFC 分布式集群来提供缓存服务。

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

mountPoint：示意挂载的 NAS 或者 CPFS 文件系统门路信息。例如：NAS 的格局为 nfs://:，CPFS 的格局为 cpfs://:；如果没有子目录要求能够应用根目录。

具体应用，请参考文档[4]：https://help.aliyun.com/document_detail/600930.html?spm=a2c4g…

replicas：示意创立的分布式集群的缓存 Worker 数量，可依据计算节点内存配置和数据集大小进行调整。倡议 quota 和 replicas 乘积大于所需缓存的数据集总大小。
network 可选值为 ContainerNetwork 和 HostNetwork。ACK 环境中倡议抉择 ContainerNetwork，应用容器网络不会有额定的性能损失。
mediumtype：示意缓存类型，只反对 HDD/SSD/MEM 中的其中一种缓存类型。其中 MEM 代表内存，举荐应用 MEM。当应用 MEM 时，path 所指定的缓存数据存储目录需为内存文件系统（例如：tmpfs）
path：示意 EFC 缓存零碎 Worker 的缓存数据存储目录。倡议放弃 /dev/shm。
quota：示意单个 Worker 组件提供的最大缓存容量。可依据计算节点内存配置和数据集大小进行调整。倡议 quota 和 replicas 乘积大于所需缓存的数据集总大小。

kubectl create -f dataset.yaml

查看 Dataset 的状况：

$ kubectl get dataset efc-demo

预期输入为：

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

您能够通过创立利用容器来应用 EFC 减速服务，或者进行提交机器学习作业来进行体验相干性能。

接下来，咱们将创立两个利用容器来拜访该数据集中的同一个大小为 10GB 的文件，您也能够应用别的文件来进行测试，该文件须要事后存储在 NAS 文件系统中。

定义如下 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

执行如下命令，查看待拜访的数据文件大小：

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

执行如下命令，查看第一个利用容器中文件的读取工夫（如果您应用本人的实在数据文件，请用实在文件门路代替 /data/allzero-demo）：

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

预期输入为：

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

接着，再另一个容器中，测试读取雷同的 10G 大小文件的耗时如果您应用本人的实在数据文件，请用实在文件门路代替 /data/allzero-demo）：

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

预期输入：

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

从上述输入信息，可发现吞吐量从原来的 648MiB/s 进步到了 1034.3MiB/s，对于雷同文件的读取效率晋升了 59.5%。

通过将 Fluid 和 EFC 相结合，能够更好地为云原生场景下的 AI 和大数据服务提供反对。这种组合能够通过标准化的数据预热和迁徙等操作，进步数据应用效率并加强自动化运维的整合。

此外，咱们还将反对 Serverless 场景下的运行，从而为 Serverless 容器提供更好的分布式文件存储拜访体验。

相干链接：

[1] Fluid

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

[2] insightface(ms1m-ibug) 数据集

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…

[4] EFC 减速 NAS 或 CPFS 文件拜访

https://help.aliyun.com/document_detail/600930.html?spm=a2c4g…

作者：之浩、展逸

点击立刻收费试用云产品开启云上实际之旅！

原文链接

本文为阿里云原创内容，未经容许不得转载。

关于云原生:为数据弹性而生阿里云云原生存储再提速

1 Fluid，云原生之数据新形象

2 EFC for 云原生存储，弹性减速保障业务稳定性

3 为数据密集利用量身打造，EFCRuntime 外围能力一览

4 训练耗时可缩短 87%，性能优于开源 NFS

5 如何疾速上手应用 EFCRuntime？

Step1：创立 Dataset 和 EFCRuntime

Step2：创立利用容器体验减速成果

6 总结和瞻望