关于腾讯云:Fluid-GooseFS-助力云原生数据编排与加速快速落地

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 相似云原生世界的“物流管理系统”，物流的收回方是各种数据源，例如 COS、HDFS、Ceph 以及 Lustre 等；此外，还要有具备存储不同货物（即聚合不同数据源）能力的物流仓库，如 GooseFS；而物流的收货地址就是用户冀望数据被应用的计算节点。

Fluid 的设计指标就是为了将货物（数据）高效、精确的投放到用户手中。在理论生存中，咱们常以快递柜的模式进行快递的散发，即在货物达到指定快递柜后心愿用户被动支付快递。这样能够防止快递积压，用户也能够弹性布局快递的支付工夫。其实设计理念体现到云计算场景就相似算子下推，将更多的计算下推到存储层实现，缩小所需传输的数据量。心愿在最初一公里实现，“挪动计算到存储”而不是“挪动存储到计算”。

数据湖加速器（Data Lake Accelerator Goose FileSystem，GooseFS），是由腾讯云推出的高牢靠、高可用、弹性的数据湖减速服务。依附对象存储（Cloud Object Storage，COS）作为数据湖存储底座的老本劣势，为数据湖生态中的计算利用提供对立的数据湖入口，减速海量数据分析、机器学习、人工智能等业务拜访存储的性能；采纳了分布式集群架构，具备弹性、高牢靠、高可用等个性，为下层计算利用提供对立的命名空间和拜访协定，不便用户在不同的存储系统治理和流转数据。

Fluid 是 CNCF Sandbox 开源的分布式数据编排和减速框架，是学术界（南京大学等）原创钻研和工业界落地实际的联合开源我的项目。在计算和存储拆散的大背景驱动下，Fluid 的指标是为 AI 与大数据云原生利用提供一层高效便捷的数据抽象，将数据从存储形象进去，以便达到：

通过 数据亲和性调度 和分布式缓存引擎减速，实现数据和计算之间的交融，从而减速计算对数据的拜访；
将数据独立于存储进行治理，并且通过 Kubernetes 的命名空间进行资源隔离，实现数据的平安隔离；
将来自不同存储的数据联结起来进行运算，从而有机会突破不同存储的差异性带来的数据孤岛效应。

从用户角度来说，用户申明数据起源后，Fluid 将主动调度数据到最合适的节点，并向外裸露 kubernetes 原生长久化数据卷。用户利用例如大数据利用 hadoop、spark 或 AI 利用 Pytorch、Tensorflow 等只须要挂载数据卷，Fluid 就能够通过亲和性调度让利用达到数据减速和对立拜访的目标。Fluid 我的项目开源短短半年多工夫内倒退迅速，吸引了泛滥大厂的专家和工程师的关注与奉献，我的项目 Adoptor 包含腾讯、微博、奇虎 360、中国电信、BOSS 直聘、第四范式等多家大型出名 IT 和互联网企业。

Fluid 与腾讯云 TKE 交融的架构如下所示，依据不同的视图分为计算调度层、存储层以及工作层，上面咱们将对该架构剥茧抽丝，带你疾速理清 Fluid、TKE、GooseFS 三者之间的关系。

计算调度层：TKE 以 Kubernetes 环境为底座提供了容器利用的部署平台，Fluid GooseFS 控制器将管制 GooseFS 实例中的 Master Pod、Worker Pod 以及 Fuse Pod 创立在最合适的 TKE Worker 节点。
存储层：控制器会依据用户指定的数据起源将底层存储例如 COS、HDFS 的数据缓存到 Worker Pod 中。
工作层：工作 pod 指定长久化存储卷，控制器 webhook 会注入亲和性信息，以实现将应用缓存工作优先调度到有缓存节点以及将不应用缓存工作先调度到没有缓存节点的指标。

总体来说，Fluid 通过云原生的架构，在数据最初一公里，通过“挪动计算到存储”的理念解决了 AI/ 大数据存算拆散场景下的诸多痛点。

以下个性均由腾讯云 TKE 团队设计奉献

在 GooseFS 分布式缓存文件系统中，高可用性蕴含两层，一是整个文件系统的可用性，二是数据的残缺和一致性。Master 作为全局元数据管理组件，通过 Master High-Availability 保障文件系统的高可用；通过 Raft 算法实现选主、状态机同步等操作保障日志和元数据的残缺和一致性。在实在业务场景下如果单个 master 呈现故障，会间接影响业务的失常运行，这就要求 Fluid 须要反对缓存引擎多 master 来保障容错率。

为了反对腾讯云 TKE 上的计算工作对缓存零碎的需要，咱们在新版本中新增了一种撑持 Fluid Dataset 数据管理和缓存的执行引擎实现。用户能够在 Fluid 中通过 GooseFSRuntime 应用 GooseFS 缓存能力进行腾讯云 COS 文件的拜访和缓存。在 Fluid 上应用和部署 GooseFSRuntime 流程简略、兼容原生 K8s 环境、开箱即用，配合腾讯云 TKE 食用更佳。

本文档将向你简略地展现上述个性

在运行该示例之前，请参考装置文档实现装置，并查看 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

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。

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]

咱们这里次要关注三个中央：

到这里，咱们曾经创立了能够供计算工作拜访的分布式缓存引擎 GooseFS，计算工作的 pod 只须要指定 persistentVolumeClaim.name 为 hbase 即可获取缓存减速的能力。
同时只须要通过指定 spec.master.replicas=n，这里 n 为大于等于 3 的奇数，就能够间接开启 Master HA 模式。
只须要指定 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 Agent 以及接入模式。目前自动化运维、多运行时反对以及接入模式根本实现，前期社区次要关注以下三个方面：

弹性拓展方面，目前曾经反对基于自定义指标对缓存 Worker 进行 HPA(Horizontal Pod Autoscaler) 以及针对业务波峰波谷的 CronHPA。然而因为缓存引擎数据再均衡（re-balance）性能的缺失，目前无奈利用扩缩容达到降本增效的目标，这个也是社区前期重点关注的个性。
Fluid Agent 方面，通过 agent push 模式，上报一些要害的运维指标例如是否有残留须要清理、节点是否有缓存等；同时不同节点上的零碎信息例如 cpu/memory 使用量、磁盘使用量、page cache 应用信息等，通过这些信息能够领导 fluid 调度器对数据集进行最优调度。
调度策略方面，目前次要波及三个方面的调度：
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 总结了目前社区曾经实现的工作以及将来的倒退布局。

总的来说，在私有云实现计算和存储的极致弹性才是增效降本的前提。只有让咱们的业务更好的应用弹性的能力，获取云原生乃至云计算最大的红利，能力让利用生于云、长于云。

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！

关于腾讯云:Fluid-GooseFS-助力云原生数据编排与加速快速落地

前言

现状和挑战

什么是存算拆散架构？

云原生存算拆散架构面临的挑战？

Fluid 能做什么？

GooseFS & Fluid 探索

云原生数据湖加速器 GooseFS

分布式数据编排和减速框架 Fluid

理清 TKE、Fluid 和 GooseFS 之间的关系

Fluid v0.6.0 个性体验

“缓存引擎高可用运行时”

“新增数据缓存引擎实现 GooseFSRuntime”

个性 Demo

前提条件

新建工作环境

查看全副节点

创立 Dataset 资源

创立并查看 GooseFSRuntime 资源

数据预热和减速

Fluid Roadmap

总结与瞻望

Just My Socks（注册教程内含优惠码）

关于腾讯云:Fluid-GooseFS-助力云原生数据编排与加速快速落地

前言

现状和挑战

什么是存算拆散架构？

云原生存算拆散架构面临的挑战？

Fluid 能做什么？

GooseFS & Fluid 探索

云原生数据湖加速器 GooseFS

分布式数据编排和减速框架 Fluid

理清 TKE、Fluid 和 GooseFS 之间的关系

Fluid v0.6.0 个性体验

“缓存引擎高可用运行时”

“新增数据缓存引擎实现 GooseFSRuntime”

个性 Demo

前提条件

新建工作环境

查看全副节点

创立 Dataset 资源

创立并查看 GooseFSRuntime 资源

数据预热和减速

Fluid Roadmap

总结与瞻望

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）