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 能做什么？

Fluid 类似云原生世界的“物流管理系统”，物流的发出方是各种数据源，例如 COS、HDFS、Ceph 以及 Lustre 等；此外，还要有具备存储不同货物（即聚合不同数据源）能力的物流仓库，如 GooseFS；