CurveFS方案设计

• 语言: 中文（简体）
• 格式: .pdf
• 来源: github.com/opencurve

摘要

该文档详细描述了CurveFS的方案设计，旨在为云原生场景提供高性能通用文件系统，重点支持数据库场景。通过调研多个开源分布式文件系统（如ChubaoFS、MooseFS、CephFS等），最终选择基于块设备构建CurveFS。文档详细阐述了元数据管理、空间分配、快照逻辑等关键点，并对元数据节点的高可用、高可扩展性、高可靠性等要求进行了分析。文档还包括了详细的开发计划及安排，确保实现满足数据库场景的文件接口需求。

AI总结

《CurveFS方案设计》文档总结

一、背景与目标
CurveFS旨在构建高性能通用文件系统，以支持云原生场景，尤其是适配云原生数据库。当前Curve已实现块存储，向上提供块设备服务，CurveFS将基于此构建。第一阶段目标是实现满足数据库场景的文件接口，长期目标是支持通用文件接口。

二、调研与对比分析
1. 开源文件系统调研
- 调研了ChubaoFS、MooseFS、FastCFS、CephFS等开源分布式文件系统
- ChubaoFS和MooseFS基于本地文件系统构建分布式FS，通过本地文件系统的打洞功能实现部分空间回收
- Bluestore和PolarFS直接基于块设备构建分布式FS，需要空间分配管理器

2. 元数据性能测试
- 测试显示MooseFS和FastCFS的元数据性能优于ChubaoFS和CephFS
- 分布式元数据设计会增加RPC交互，影响性能

3. 方案对比与选择
- 基于本地文件系统方案：工作量大，快照逻辑无法复用
- 基于块设备方案：可复用快照逻辑，设计更简洁
- 综上，选择基于块设备构建CurveFS

三、架构设计
1. 卷和文件系统
- 基于现有块设备实现文件系统

2. 元数据管理
- 采用Dentry与Inode两层结构
- 元数据分片存储，使用Multi-Raft保证一致性和高可用性

3. 文件系统快照
- 方案一：文件/目录级别快照，适合复制场景，但需要实现新快照逻辑
- 方案二：文件系统快照，复用现有逻辑，适合备份场景
- 综上，选择方案二，实现简单，能满足备份需求

四、关键设计点
1. 元数据设计
- 采用Dentry和Inode两层结构
- 通过共享InodeID实现数据共享
- 数据持久化采用Raft协议，确保高可用性

2. 文件空间管理
- 通过inode的blk_list记录文件占用的块设备空间
- 空间分配信息缓存在Client或Metaserver，无需额外持久化

3. 元数据节点
- 要求：高可用、高可扩、高可靠、高性能
- 采用Master-Slave模式，Slave缓存所有元数据

五、开发计划
1. 元数据节点开发
- 2021-05-13：确认数据结构与内存组织形式
- 2021-05-20：完成代码框架与接口对接
- 2021-05-28：完成模块开发

2. 空间分配开发
- 2021-05-14：确认空间分配方案
- 2021-05-20：完成代码框架与接口对接
- 2021-05-28：完成模块开发

3. Client端开发
- 2021-05-19：完成接口及流程确认
- 2021-05-27：完成代码框架开发
- 2021-06-09：完成主要接口开发

4. 联调与测试
- 2021-06-10起：进行全面联调与测试