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

Razor

2019/10/19 发布于 技术 分类

文字内容
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