ChubaoFS：云原生的开源分布式文件系统及应用实践 刘硕然

2020-03-01 327浏览

  • 1.ChubaoFS：云原生的开源分布式文 件系统及应用实践 刘硕然 资深软件开发工程师
  • 2.自我介绍
  • 3.自我介绍 京东技术架构部资深软件开发工程师，分布式文件存储负责人。有多年文件系统， Linux 内核及分布式存储经验。目前负责开源分布式文件系统 ChubaoFS 的研发及生 态拓展。ChubaoFS 在京东已经服务超过 100 个业务方及应用服务，为大规模容器集 群提供持久化存储方案。
  • 4.目录 • 云原生应用存储现状 • ChubaoFS带来的变革 • 架构设计 • 典型应用支撑实践 • 云原生社区现状 • 后续工作及收益
  • 5.云原生应用存储现状 本地文件系统 • 需要POSIX语义并且对性能要求比较高的应用，目前很多会采用本地文件系统，原因 是POSIX语义在性能上并不适合分布式系统 • 应用容器的调度被局限在特定的物理节点，物理节点故障需要数据迁移，与云原生的 理念背道而驰 • 如果应用需要高可用，需要自己来做Replication和Failover • 容量受到局限，扩容较复杂 生态强相关的分布式文件系统 • 如Hbase+HDFS • 需要给特定应用单独部署集群，资源使用率较低
  • 6.云原生应用存储现状 Cont’d 对象存储 • 应用需要使用对象存储接口，一般自研应用使用较多，一些传统的数据库应用无法使 用，如数据库备份场景 • 不适合顺序追加写的场景，追加需要读取整个blob 分布式块存储 • 应用使用块存储接口的开发成本较高，一般自研应用使用较少
  • 7.云原生应用存储现状 Cont’d 为什么不用通用分布式文件系统 • 设计复杂，运维难度高，需要专业的运维团队 • 大文件顺序读写性能较好，但是对于小文件的支持较差 • 高并发的元数据操作会有热点问题 • 多租户的支持较差，提供基础设施的部门经常需要给每个大的业务方部署单独集群 • POSIX语义并不适合分布式系统，性能成为瓶颈
  • 8.ChubaoFS带来的变革 设计理念 • 在资源有限的情况下（存储介质、网络等），tradeoff妥协是不可避免的，评判标准 是满足上层业务的需求 • 保持简单设计 -> 系统稳定性提高 -> 运维负担降低 • 允许业务方bluffing
  • 9.ChubaoFS带来的变革 – 应用层面 应用无状态化 • 客户端基于FUSE框架，使用挂载的方式，提供POSIX文件系统接口 • 使用本地文件系统的应用可以平滑迁移到ChubaoFS分布式文件系统 • 云原生应用调度不再受物理节点限制，真正体现cloud native 可靠的分布式文件系统性能 • 尽可能遵循POSIX语义，以满足应用需求为准，例如，Hbase，MySQL， Elasticsearch，TensorFlow，Spark等常见应用均可直接跑在ChubaoFS上 • 支持跨客户端写同一个文件不同位置，但是写相同位置没有明确定义 • 不支持跨节点客户端的O_APPEND写请求
  • 10.ChubaoFS带来的变革 - 应用层面 Cont’d 可扩展性 • 理论上容量可以无限扩容，应用无需关注存储资源 高可用 • 应用不需要考虑高可用性，专注于业务即可
  • 11.ChubaoFS带来的变革 – 基础设施层面 统一存储资源 • 替换本地文件系统，及传统的分布式文件系统，CephFS，MooseFS，GlusterFS， HDFS等，无需单独部署集群 • 集群支持多租户，不同应用共享存储资源，提高资源利用率 运维简单 • 所有管理命令均可通过Http请求完成，无需专业的运维团队
  • 12.架构设计
  • 13.架构设计 - Data Subsystem 框架 • 集群由若干data nodes组成（物理） • 每个data node包含若干partitions（逻辑） • 每个partition包含若干extent file 大小文件构成 • 大文件由多个extent组成 • 小文件聚合至预分配extent • 小文件删除使用punch hole 复制协议 • 顺序写 primary-backup protocol • 覆盖写 multi-raft protocol
  • 14.架构设计 - Meta Subsystem Distributed in-memory storage for meta data • 复制协议使用multi-raft • 元数据持久化由Raft日志及snapshot保证 • 所有元数据缓存在内存中 框架 • 集群由若干meta nodes组成 • meta nodes包含若干partitions • 每个partition由三台nodes组成Raft复制组 应对高并发及大量小文件操作 • inode不局限于父目录所在的partition • 允许存在inode无对应dentry，不允许存在dentry无对应inode
  • 15.Spark on ChubaoFS 现状 • 目前业界普遍的观点是，出于性能考虑，原生Spark不能直接使用分布式文件系统， 一般使用本地文件系统。 • Spark应用运行在容器中，被Kubernetes调度时，会有局限性 • 基础设施部门也无法预知需要提供多少存储资源，造成资源利用率降低 • Spark应用如果使用分布式文件系统，一般会接external shuffle service模块，增加 开发成本 真的没有办法吗？ • 通过分析shuffle读写模型发现两个特点：顺序写，且write/fsync比率较高；任务中 写入的数据较短时间内会被再次读到。
  • 16.Spark on ChubaoFS Cont’d • 使能FUSE writeback feature，调整一些Spark参数，ChubaoFS完全可以达到与本 地文件系统接近的性能 • 真实Spark业务及TeraSort均有测试
  • 17.ElasticSearch on ChubaoFS 现状 • 大部分都在使用本地文件系统 • 容器集群中，造成资源利用率低，且不容易扩容 替代本地文件系统 • 同等存储介质条件下（SSD，SAS/SATA HDD），TPS是本地文件系统的80%左右， 考虑到使用分布式存储的巨大收益，性能在业务方接受范围内 • 动态扩容，无需关注容量资源 • 零副本，高可用由分布式文件系统保证
  • 18.云原生社区现状 – 开发相关 Kubernetes CSI driver • 支持Container Storage Interface Spec v0.3 和 v1.0 • 可以PV/PVC方式使用ChubaoFS • 避免容器中的mount操作，更好的安全性，因为mount操作需要容器privileged启动 • 与应用的容器隔离，避免用户态客户端进程被误杀 • 动态创建删除Volume，无需提前静态创建 • 风险：每个Volume都在宿主机有挂载点，目前Kubernetes在调度时并未考虑挂载数量 这一因素，有可能造成某个物理节点挂载过多 Helm/Operator (WIP) • 进一步简化server端的部署和运维
  • 19.云原生社区现状 – 社区相关 CNCF社区 • CNCF Landscape，https://landscape.cncf.io/selected=chubao-fs• CNCF Storage SIG audit（done） • Preparing TOC Sandbox presentation 前景展望 • 分布式文件系统在云原生社区的应用并不广泛，目标是通过更加中立和开放的平台CNCF， 改变大家对于分布式文件系统的固有印象，为云原生应用选择存储方案时提供更多选择 OpenSDS/SODA社区 • ChubaoFS filesystem driver合入主干
  • 20.后续工作及收益 支持部分对象存储接口协议 • 打通文件系统和对象存储，一份数据可以通过两种协议访问 Erasure Coding • 冷数据备份场景下，可以使用EC volume，进一步节省存储资源 详细开发任务列表 •https://github.com/chubaofs/chubaofs/projects/1
  • 21.Misc • 开源 github.com/chubaofs/chubaofs • Apache 2.0 • Haifeng Liu, et al.,CFS:A Distributed File System for Large Scale Container Platforms. SIGMOD ’19, June 30-July 5, 2019, Amsterdam, Netherlands.https://dl.acm.org/citation.cfm?doid=3299869.3314046
  • 22.
  • 23.