作者:东伝
背景
数据关于当今互联网业务的重要性不言而喻,它几乎渗透到了当今这个国际的每一个旮旯。但单有数据是不行的,真实让数据发生价值的,是针对各业务场景运转的对很多数据的密布剖析与核算,如机器学习、大数据剖析、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
例如,上方示例展现了 FluidDataset 的相关信息
- 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 进行数据拜访前履行数据缓存预热是一个“磨刀不误砍柴工”的必要操作。
- 创立DataLoadCR
在 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),F luid 的数据分流机制可以为 Serverless 运用供给更大的有用拜访带宽,而且该带宽可经过添加缓存 Worker 节点数量弹性提高。
*有用数据拜访带宽=Serverless 数据拜访Pod 数量x每 Pod 拜访的数据量/数据拜访运用整体耗时
作用 2:因数据拜访加快而下降的费用本钱
图 2直接拜访OSSvs.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 弹性算力真实做到物尽其用。
图 3ArgoWorkflow 使命耗时比照
总结
本文展现了一个在 ASK 环境中运转 Fluid 的完好数据拜访示例,希望可以协助咱们了解 Fluid 的运用体验、运转作用以及 Serverless 和数据密布型运用结合的更多可行性。详细而言,咱们看到:
- 用户运用 Fluid 拜访数据是简略易用的:用户只需求把本来拜访 OSS 的 PVC 修改为 Fluid Dataset 对应的 PVC。
- Fluid 可以供给可弹性弹性的数据拜访带宽,协助规模化的数据拜访运用提高数据读取功率。
- 因为数据读取功率的提高,Fluid 可以协助规模化的数据拜访运用大幅下降费用本钱。
参阅链接
[1] 如何创立 ASK 集群:
help.aliyun.com/document_de…
[2] ACK 云原生 AI套件概况:
help.aliyun.com/document_de…
[3] Fluid 项目 github 地址:
github.com/fluid-cloud…
点击此处,请求 ACK 云原生 AI 套件免费体验座位!