关于后端:Fluid-助力阿里云-Serverless-容器极致提速

6次阅读

共计 9959 个字符，预计需要花费 25 分钟才能阅读完成。

简介：本文展现了一个在 ASK 环境中运行 Fluid 的残缺数据拜访示例，心愿可能帮忙大家理解 Fluid 的应用体验、运行成果以及 Serverless 和数据密集型利用联合的更多可行性。作者：东伝背景数据对于当今互联网业务的重要性显而易见，它简直渗透到了当今这个世界的每一个角落。但单有数据是不够的，真正让数据产生价值的，是针对各业务场景运行的对大量数据的密集剖析与计算，如机器学习、大数据分析、OLAP 聚合剖析等等。近些年，随着数据规模的增大，这些对于资源有着更高要求的数据密集利用天然地导向了以弹性资源著称的云服务。在这种数据密集利用上云的趋势下，Serverless 仿佛并不是这个趋势的显著受益者。只管简直所有人都对这种计算资源有限扩容、弹性麻利交付、低运维老本的架构不吝赞美之词，但因为它将计算存储拆散的架构推向了一个更纯正的极其，具备强数据依赖的数据密集利用想要高效运行于 Serverless 环境变得极其艰难。举例来说，如果咱们想将 AI 推理服务利用部署在 Serverless 架构下，每个服务利用启动前必须将寄存在内部存储系统的 AI 模型首先拉取到本地内存中。思考到近年来 AI 大模型曾经成为业界支流，让咱们假如这个 AI 模型的大小为 30GB，并且存储于 OSS 对象存储服务中，如果须要同时启动 100 个这样的 AI 推理服务利用，那么总共的数据读取量就是 3000GB。OSS 存储默认的数据拜访限速是 10Gbps，这就意味着 100 个利用都须要期待 2400 秒（3000GB 8 / 10Gbps）才能够真正开始对外提供服务。如果每个服务咱们创立一个 ecs.gn7i-c32g1.16xlarge 的实例（按每小时单价折算每秒 0.008 元），这意味着光在期待数据上就曾经花掉了 1920 元（0.008 元 / 秒 2400 秒 100）。总结来说，咱们大量的费用没有花在产生价值的计算上，这显然不是咱们想要的。（理论价格以阿里云官网显示为准）那么，有没有什么办法能够优化上述过程？这就引入了本文的配角：Fluid。Fluid 是一个 Kubernetes 原生的分布式数据集编排和减速引擎。Fluid 诞生的初衷即是为利用的数据拜访延时问题提供云原生的解决方案。对于困扰着 Serverless 数据密集利用的上述相干问题，Fluid 在保障用户简略易用的应用体验前提下，给出了一套 Serverless 环境新的数据拜访架构计划，帮忙用户晋升数据拜访效率。

本文将 step by step 地介绍 Fluid 的运行示例，帮忙大家理解如何在阿里云 ASK（Alibaba Serverless Kubernetes）环境中应用 Fluid，展现如何借助 Fluid 实现 zero to zero 的（从零资源应用开始到全副资源开释完结）规模化数据密集型工作执行模式，并获得降本提速的成果。Fluid on ASK 运行示例 Fluid 数据编排减速 Serverless Kubernetes 性能尚处于公测阶段，可点击浏览原文申请体验席位。Fluid 部署在运行以下示例前，首先须要搭建一个 ASK 集群，并配置好连贯该集群的 Kubeconfig。相干步骤可参考文末文档《如何创立 ASK 集群》。在应用 Fluid 的各项性能前，须要将 Fluid 的各管制面组件部署到 ASK 集群中。这个部署过程能够通过阿里云容器服务 -Kubernetes 控制台轻松实现。如下图所示：

抉择 ASK 集群面板右侧的“利用 -Helm”子面板点击 ” 创立 ” 按钮在 Chart 市场中搜寻 ack-fluid 即可找到 Fluid 对应的 Helm Chart，填写“利用名”（例：ack-fluid)。点击“下一步”后，抉择应用默认的 fluid-system 作为部署的命名空间接着无需对 Chart Values 进行任何批改，间接点击“确定”，即可将 Fluid 部署到 ASK 集群中。在配置完 ASK 集群对应的 Kubeconfig 信息后，输出以下命令：$ kubectl get pod -n fluid-system 能够察看到 Fluid 的几个组件曾经失常运行起来：NAME READY STATUS RESTARTS AGE
dataset-controller-d99998f79-dgkmh 1/1 Running 0 2m48s
fluid-webhook-55c6d9d497-dmrzb 1/1 Running 0 2m49s 其中：Dataset Controller：负责保护各个 Fluid 所引入的 Dataset CRs 的残缺生命周期。Fluid Webhook: 负责对用户须要拜访数据的利用 Pod 进行自动化变换（Mutation），无感知地帮忙用户实现 Serverless 场景的数据拜访性能。除了上述形容的两个组件外，Fluid 的管制面依然蕴含了一些与各类缓存零碎（例如：JindoFS、JuiceFS、Alluxio 等）严密关联的控制器组件，这些组件在初始部署状态下不会创立，仅当用户指定须要应用某种缓存零碎时，与其相关联的缓存零碎控制器组件 Pod 才会按需扩容，从而在按量付费的 ASK 环境中尽可能地帮忙用户节省成本。数据缓存部署 Fluid 世界中的所有都以 Dataset 这一自定义资源为核心：无论是对外部存储中已有数据的形象治理还是利用 Pod 的数据拜访，用户都须要和 Dataset 资源进行交互。每当用户创立一个 Dataset CR 并指定了它的缓存零碎后端，Fluid 就会主动地将数据缓存部署到 Kubernetes 集群中。在上面的实际过程中，咱们以阿里云 OSS 对象存储作为内部存储系统为例，模仿一个残缺的“缓存部署 - 数据拜访 - 资源回收”的规范数据应用过程。数据文件筹备首先，筹备一个待拜访的文件。例如，这里咱们应用 dd 命令疾速创立一个大小约为 30G 的文件：$ cd $(mktemp -d)

$ dd if=/dev/zero of=./largefile-30G bs=10M count=3072

3072+0 records in
3072+0 records out
32212254720 bytes (32 GB) copied, 108.189 s, 298 MB/s

$ ls -lh ./largefile-30G
-rw-r–r– 1 root root 30G Sep 7 21:11 ./largefile-30G 接着，把上述创立的待拜访文件上传到 OSS Bucket 中，这里以一个位于 Beijing Region 的名为 fluid-demo 的 OSS Bucket 为例。$ ossutil cp -i <access_key_id> -k <access_key_secret> -e oss-cn-beijing-internal.aliyuncs.com ./largefile-30G oss://fluid-demo/ 创立 Fluid Dataset 和 Runtime 资源数据筹备和上传后，即可在 Fluid 中申明上述待拜访的数据。具体而言，咱们须要提交一个 Dataset CR 和一个 Runtime CR。Dataset CR 中形容数据在内部存储系统中的 URL 地位，Runtime CR 形容缓存零碎及零碎具体配置。首先，把拜访 OSS Bucket 所需的身份凭证信息存储于 Secret 中：$ kubectl create secret generic oss-access-key \
–from-literal=fs.oss.accessKeyId=<access_key_id> \
–from-literal=fs.oss.accessKeySecret=<access_key_secret> 接着，定义 Dataset CR 和 Runtime CR。这里咱们抉择 JindoFS 作为缓存零碎后端，Fluid Runtime 资源为 JindoRuntime: apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
name: demo-dataset
spec:
mounts:

- mountPoint: oss://fluid-demo # OSS Bucket URL
  name: demo
  path: /
  options:
    fs.oss.endpoint: oss-cn-beijing-internal.aliyuncs.com # OSS Bucket 内网拜访端点
  encryptOptions:
    - name: fs.oss.accessKeyId
      valueFrom:
        secretKeyRef:
          name: oss-access-key
          key: fs.oss.accessKeyId
    - name: fs.oss.accessKeySecret
      valueFrom:
        secretKeyRef:
          name: oss-access-key
          key: fs.oss.accessKeySecret

apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
name: demo-dataset
spec:
# 缓存 Worker 节点数量
replicas: 5
podMetadata:

annotations:
  # 抉择 JindoFS Pod 应用的实例规格
  k8s.aliyun.com/eci-use-specs: ecs.d1ne.6xlarge
  # 启用实例镜像缓存，减速 Pod 启动过程
  k8s.aliyun.com/eci-image-cache: "true"

tieredstore:

levels:
  # 以 40GiB 的内存作为每个缓存 Worker 节点的缓存介质
  - mediumtype: MEM
    volumeType: emptyDir
    path: /dev/shm
    quota: 40Gi
    high: "0.99"
    low: "0.99" 创立上述 Dataset CR 和 JindoRuntime CR 到 ASK 集群：$ kubectl create -f dataset.yaml 查看 Dataset 部署状态 Dataset CR 和 JindoRuntime CR 创立后，约 1 到 2 分钟后，Dataset 将部署实现，届时能够查看到与缓存零碎以及后端存储系统中数据的相干信息。$ kubectl get dataset demo-dataset

NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE
demo-dataset 30.00GiB 0.00B 200.00GiB 0.0% Bound 2m9s 例如，上方示例展现了 Fluid Dataset 的相干信息 OSS 中数据集总大小(UFS TOTAL SIZE)：30.00GiB 以后缓存量（CACHED）：0.00B 缓存零碎容量（CACHE CAPACITY）：200.00GiB 数据集缓存百分比（CACHED PERCENTAGE）：0.0%Dataset 状态（PHASE）：Bound，示意已胜利部署。数据缓存预热 Fluid 实现的 Kubernetes 集群内数据拜访减速不是什么 Magic Trick：其本质是通过数据分流（Data Offloading）来升高核心存储的拜访压力：Fluid 会把须要拜访的数据缓存到与利用 Pod 更近的分布式缓存零碎（例如：JindoFS、JuiceFS、Alluxio 等）中，于是，与缓存零碎位于同一 VPC 网络的利用 Pod，就可能以远比间接拜访核心存储带宽更高的 VPC 内网带宽进行数据拜访。进一步地，因为对接的是分布式缓存零碎，所以当单个缓存零碎 Worker 节点提供带宽有余时，可将分布式缓存零碎扩容，从而实现数据拜访带宽的弹性伸缩，匹配 Serverless 场景下的计算资源弹性。因而，为了通过数据分流实现高带宽数据拜访，在利用 Pod 进行数据拜访前执行数据缓存预热是一个“磨刀不误砍柴工”的必要操作。创立 DataLoad CR 在 Fluid 中执行数据缓存预热只需创立如下的 DataLoad CR：apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
name: demo-dataset-warmup
spec:
# 指定须要预热的 Dataset
dataset:

name: demo-dataset
namespace: default

loadMetadata: true
target:

- path: / # 指定预热的数据子门路，“/”示意预热整个数据集
  replicas: 5 # 预热后数据在缓存零碎中的正本数量 $ kubectl create -f dataload.yaml 查看预热后 Dataset 状态 查看 DataLoad CR 状态，直至其 PHASE 变为 Complete 状态：$ kubectl get dataload demo-dataset-warmup

NAME DATASET PHASE AGE DURATION
demo-dataset-warmup demo-dataset Complete 2m38s 2m20s 通过 Duration 能够查看数据预热消耗的工夫，上述示例中预热耗时为 2m20s。在数据缓存预热实现后，Dataset 上相干的缓存状态也会随即更新：$ kubectl get dataset demo-dataset
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE
demo-dataset 30.00GiB 150.00GiB 200.00GiB 100.0% Bound 8m27s 能够看到，数据预热实现后，整个数据集都曾经被缓存在了分布式缓存零碎中，缓存比例 100.0%，因为预热时指定了预热的缓存正本数量为 5，预热后缓存占用总量为数据集大小的 5 倍。注：减少缓存正本数量有助于加重数据拜访时对分布式缓存 Worker 节点的单点拜访性能瓶颈。数据拜访紧接着，尝试创立利用 Pod 来拜访 OSS 中的数据。咱们将会一次性拉起 100 个利用 Pod，让这些 Pod 同时拜访 OSS 中的数据文件。这样的数据读取模式在 AI 推理服务弹性扩容、主动驾驶仿真等具体场景中都非常常见。创立数据拜访利用例如：上面是一个 Argo Workflow 利用示例：apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: parallelism-fluid-
spec:
entrypoint: parallelism-fluid
# Argo Workflow Task 最大并发数，即同时启动 100 个 Pod
parallelism: 100
podSpecPatch: ‘{“terminationGracePeriodSeconds”: 0}’
podMetadata:

labels:
  # 增加如下 label 关上 Fluid 对 Serverless 场景的数据拜访反对
  alibabacloud.com/fluid-sidecar-target: eci
annotations:
  # 启用实例镜像缓存，减速 Pod 启动过程
  k8s.aliyun.com/eci-image-cache: "true"
  # 抉择 Argo Workflow Pod 应用的实例规格
  k8s.aliyun.com/eci-use-specs: ecs.g6e.4xlarge

templates:

name: parallelism-fluid
steps:
- - name: domd5sum
    template: md5sum
    withSequence:
    start: “1”
    end: “100”
name: md5sum
container:
imagePullPolicy: IfNotPresent
image: alpine:latest
# 每个 pod 计算待读取文件的 md5sum
command: [“/bin/sh”, “-c”, “md5sum /data/largefile-30G”]
volumeMounts:
- name: data-vol
  mountPath: /data
volumes:
- name: data-vol
  persistentVolumeClaim:
  claimName: demo-dataset # claimName 须与 Fluid Dataset 名字统一 $ argo submit workflow.yaml 查看数据拜访利用状态上述示例的 Argo Workflow 将会一次性拉起 100 个 Pod 进行并行数据拜访。待上述 100 个 Pod 全副实现后，能够看到如下后果：$ argo list

NAME STATUS AGE DURATION PRIORITY
parallelism-fluid-x677t Succeeded 8m 5m 0 查看工作的具体信息：$ argo get parallelism-fluid-x677t
Name: parallelism-fluid-x677t
Namespace: default
ServiceAccount: unset (will run with the default ServiceAccount)
Status: Succeeded
Conditions:
PodRunning False
Completed True
Created: Wed Sep 07 21:25:30 +0800 (7 minutes ago)
Started: Wed Sep 07 21:25:30 +0800 (7 minutes ago)
Finished: Wed Sep 07 21:31:28 +0800 (1 minute ago)
Duration: 5 minutes 58 seconds
Progress: 100/100
ResourcesDuration: 8h10m22s(1 alibabacloud.com/vfuse),24h15m6s(1 cpu),24h15m6s*(100Mi memory)

STEP TEMPLATE PODNAME DURATION MESSAGE
✔ parallelism-fluid-x677t parallelism-fluid
└─┬─✔ domd5sum(0:1) md5sum parallelism-fluid-x677t-2855796525 5m
├─✔ domd5sum(1:2) md5sum parallelism-fluid-x677t-1226856655 5m
├─✔ domd5sum(2:3) md5sum parallelism-fluid-x677t-2858910973 5m
├─✔ domd5sum(3:4) md5sum parallelism-fluid-x677t-2609269875 4m
├─✔ domd5sum(4:5) md5sum parallelism-fluid-x677t-616770109 5m
├─✔ domd5sum(5:6) md5sum parallelism-fluid-x677t-3071900311 5m
├─✔ domd5sum(6:7) md5sum parallelism-fluid-x677t-3841084237 5m
├─✔ domd5sum(7:8) md5sum parallelism-fluid-x677t-120540963 5m
├─✔ domd5sum(8:9) md5sum parallelism-fluid-x677t-1353329645 5m
├─✔ domd5sum(9:10) md5sum parallelism-fluid-x677t-2391364586 5m
├─✔ domd5sum(10:11) md5sum parallelism-fluid-x677t-4083824607 5m
├─✔ domd5sum(11:12) md5sum parallelism-fluid-x677t-258640575 5m
├─✔ domd5sum(12:13) md5sum parallelism-fluid-x677t-3913466863 5m
├─✔ domd5sum(13:14) md5sum parallelism-fluid-x677t-1949266799 5m
├─✔ domd5sum(14:15) md5sum parallelism-fluid-x677t-214569823 5m
├─✔ domd5sum(15:16) md5sum parallelism-fluid-x677t-684353087 5m 能够看到，整个工作的运行时长为 5m58s。资源回收数据缓存资源回收用户能够在不再须要数据缓存时，将缓存从 ASK 集群中回收以节俭集群资源并降低成本。Fluid 中对于缓存零碎的回收仅须要将关联的 Fluid Dataset 删除，例如：$ kubectl delete dataset demo-dataset 执行上述删除命令后期待一段时间（Fluid 将会进行一些清理工作），缓存零碎的相干 Pod 都会被回收。Fluid 管制面组件回收在缓存零碎相干 Pod 回收后，用户同样能够试状况回收管制面组件占用的资源。执行上面的脚本，缩容管制面组件。$ kubectl get deployments.apps -n fluid-system | awk ‘NR>1 {print $1}’ | xargs kubectl scale deployments -n fluid-system –replicas=0 当再次须要应用 Fluid 时，执行上面的扩容命令，创立新的管制面组件 Pod 即可：$ kubectl scale -n fluid-system deployment dataset-controller –replicas=1

$ kubectl scale -n fluid-system deployment fluid-webhook –replicas=1 计划成果屡次运行上述示例，并调整缓存零碎 Worker 的数量（5 个或 10 个）或抉择间接拜访 OSS 对象存储，咱们失去了如下成果数据：成果 1：可弹性伸缩的数据拜访带宽

图 1 缓存 / 存储系统提供的无效数据拜访带宽比照依据数据拜访利用的整体耗时、拜访的数据文件大小以及数据拜访的 Pod 数量，咱们能够计算出图 1 中的“无效数据拜访带宽 ”性能体现。从图 1 来看，相比于 OSS 存储系统提供的默认带宽（10Gbps），Fluid 的数据分流机制能够为 Serverless 利用提供更大的无效拜访带宽，并且该带宽可通过减少缓存 Worker 节点数量弹性晋升。无效数据拜访带宽 = Serverless 数据拜访 Pod 数量 x 每 Pod 拜访的数据量 / 数据拜访利用整体耗时成果 2：因数据拜访减速而升高的费用老本

图 2 间接拜访 OSS vs. Fluid 老本比照上述示例中咱们应用如下的 ECI 实例规格：Argo Workflow 工作 Pod：ecs.g6e.4xlarge (每秒单价 0.0012 元)缓存零碎 Pod：ecs.d1ne.6xlarge (每秒单价 0.0056 元) 由此可计算失去“图 2 间接拜访 OSS vs. Fluid 老本比照”。察看图 2 不难发现，通过 Fluid 拜访 OSS 中的数据可能将老本削减为原来的约六分之一到八分之一。另外，在同样应用 Fluid 拜访数据的前提下，应用更多的缓存 Worker 节点能够节俭更多老本。这背地的次要起因是 Fluid 提供了更大的数据拜访带宽，从而使得数据拜访性能晋升，缩短了利用花在数据读取上的工夫（见图 3），从而使得购买的 Serverless 弹性算力真正做到物尽其用。

图 3 Argo Workflow 工作耗时比照总结本文展现了一个在 ASK 环境中运行 Fluid 的残缺数据拜访示例，心愿可能帮忙大家理解 Fluid 的应用体验、运行成果以及 Serverless 和数据密集型利用联合的更多可行性。具体而言，咱们看到：用户应用 Fluid 拜访数据是简略易用的：用户只须要把原来拜访 OSS 的 PVC 批改为 Fluid Dataset 对应的 PVC。Fluid 可能提供可弹性伸缩的数据拜访带宽，帮忙规模化的数据拜访利用晋升数据读取效率。因为数据读取效率的晋升，Fluid 可能帮忙规模化的数据拜访利用大幅升高费用老本。参考链接 [1] 如何创立 ASK 集群：https://help.aliyun.com/docum… [2] ACK 云原生 AI 套件详情：https://help.aliyun.com/docum… [3] Fluid 我的项目 github 地址：https://github.com/fluid-clou… 点击此处，申请 ACK 云原生 AI 套件收费体验席位！原文链接：https://click.aliyun.com/m/10… 本文为阿里云原创内容，未经容许不得转载。

正文完