CurveFS 预览版重磅首发，Curve 加速迈向云原生软件定义存储
今天，我们很高兴地发布 Curve 项目的文件系统，以及全新的部署工具。这也是 CurveFS 的第一个 beta 版本，预示着在 Curve 社区同仁的共同努力之下，Curve 距离更好用的云原生软件定义存储又前进了一步。
版本地址：
https://github.com/opencurve/curve/releases/tag/v0.1.0-beta
2021 年上半年 Curve 团队立项决定做分布式共享文件系统，我们的Roadmap列出了一些打算实现的关键特性，其中包括：
提供基于 FUSE 的用户态的文件读写接口，并且兼容 POSIX 协议
支持数据存储到对象存储系统
支持云原生部署、运维、使用
支持多文件系统
CurveFS 的首发版本当前已实现上述功能，更多的功能仍在开发当中，欢迎试用体验。
为什么要做 CurveFS
支持多领域数字业务发展，将 Curve 开源的网易数帆存储团队，在实践中先一步感受到了新一代分布式文件系统的需求，并得到了 Curve 社区成员的共鸣。
从跟网易内部产品以及数帆商业化客户沟通，用户使用的分布式文件系统主要是 CephFS（配合 Kubernetes 做 PV 使用），在近几年的使用过程中，用户在如下几个场景遇到了难以彻底解决的问题：
场景 1：期望兼顾性能和容量的机器学习场景
某业务机器学习场景下，在使用 CephFS 过程中，训练耗时期望尽量短，训练结果期望长期保存，但访问频次很低，因此希望可以主动/被动沉淀到容量型存储池，需要用到的时候可以主动/被动触发迁移到性能型存储池。这里的主动是指业务可以自行切换某个目录的存储类型（如容量型、性能型），被动是指通过配置一定的生命周期规则（或缓存管理策略）来触发存储池切换。
CurveFS 在这个场景下，可以通过多级缓存（CurveFS client 端内存缓存、client 端硬盘缓存，基于 CurveBS 的数据缓存，基于 CurveBS 的高性能数据池）来加速训练样本的读写，而冷数据则放到容量型的存储池也即对象存储上。当用户想要训练某个已经沉淀到冷数据池的样本集时，可以提前主动预热这部分数据来加速训练过程（也可以被动加载）。这部分功能会在后续版本中支持。
场景 2：期望快速跨云弹性发布的业务 B
正常情况下，私有化部署一个 CephFS 集群要准备多台存储节点，涉及到较长时间的机器准备、上架等操作。而在公有云场景部署一个自己的存储集群一般是不太实际的，因此一般使用公有云提供的存储服务。对于想要多云统一管理的业务，则需要进行相应的开发。我们期望可以做到一键部署到多种公有云上，对业务提供统一的使用逻辑。辑。
CurveFS 在这个场景下可以通过已有的对象存储服务快速的部署一套几乎无容量上限的分布式共享文件系统，而且部署过程非常简单快速。另外如果对象存储引擎的性能无法满足需求，CurveFS 还可以通过云硬盘如 EBS、ESSD 等来加速读写（既可以做 client 端缓存，又支持做服务端缓存）。
基于对象存储的存储引擎，跨云部署也非常方便，运维人员简单的修改几个参数就可以使用同一套部署工具搞定跨云部署。
场景 3：低成本大容量需求的业务 C
容量需求是首要的，但写入速度要快，目前都是 3 副本场景，成本稍高，希望能支持。CurveFS 在这个场景下，可以通过客户端的内存缓存、硬盘缓存来加速写入速度，之后异步上传到低成本的对象存储集群（通常采用 EC 纠删码来降低副本冗余）。对于不想采购存储服务器部署存储集群的用户来说，使用公有云的对象存储服务来实现低成本大容量的存储需求是比较合算的。
场景 4：ES 中间件冷热数据自动分离
热数据放在高性能的存储硬件，冷数据放在低性能容量型存储硬件，需要手工配置，希望能自动化在底层存储引擎做掉。CurveFS 在这个场景下，可以通过热数据放在 3 副本的 CurveBS 集群中，冷数据根据配置好的生命周期规则，到达一定时间没有访问后，转存到对象存储集群中。
场景 5：某业务 S3 和 POSIX 统一访问需求
期望通过挂载 fuse 客户端生产数据，通过 S3 接口访问数据。CurveFS 后续会支持 S3 协议访问文件系统中的文件，同时支持 S3 协议和 POSIX 协议，另外支持 S3 协议后，Curve 将成为一个同时支持块、文件、对象存储的统一存储系统，为用户带来更多的便利。
未来规划场景：
Curve 作为多种存储系统（如 HDFS、S3 兼容对象存储等）的统一存储层，接管并加速各系统访问。Curve 后续将支持接管多种存储系统，并进行统一的 cache 加速。
当然我们在使用 CephFS 过程中还遇到了一些难以通过修改配置，或者简单的二次开发解决掉的问题，这也是促使我们自研的动力来源：
部分场景下性能瓶颈严重：尤其是元数据时延方面，即使启用了多 MDS+静态目录绑定、元数据存储池使用 SSD 盘、甚至使用内核态客户端等前提下，仍然不能很好的满足业务诉求
可用性风险高：多 MDS 场景+静态目录绑定功能开启后，一旦某个主 MDS 故障，切换时间会比较长，期间业务会中断
元数据负载均衡问题：静态目录绑定勉强可用，但可运维性不足，实施困难；动态目录迁移目前可用性较差，会造成频繁的反复迁移，影响元数据访问的稳定性
元数据锁实现逻辑复杂、难以理解、学习门槛过高：功能全面，但性能难免会受影响，另外开发人员维护难度大增，二次开发困难，遇到问题分析起来也很吃力
均衡性问题：Ceph 通过 crush 算法来放置对象，该算法可能导致集群均衡性不是特别理想，故而会形成短板效应，导致集群可用容量较少，成本升高
CurveFS 架构设计
CurveFS 的架构如下图所示：
CurveFS 由三个部分组成：
客户端 curve-fuse，和元数据集群交互处理文件元数据增删改查请求，和数据集群交互处理文件数据的增删改查请求。
元数据集群 metaserver cluster，用于接收和处理元数据(inode 和 dentry)的增删改查请求。metaserver cluster 的架构和 CurveBS 类似，具有高可靠、高可用、高可扩的特点：
MDS 用于管理集群拓扑结构，资源调度。
metaserver 是数据节点，一个 metaserver 对应管理一个物理磁盘。CurveFS 使用 Raft 保证元数据的可靠性和可用性，Raft 复制组的基本单元是 copyset。一个 metaserver 上包含多个 copyset 复制组。
数据集群 data cluster，用于接收和处理文件数据的增删改查。data cluster 目前支持两存储类型：支持 S3 接口的对象存储以及 CurveBS（开发中）。
主要功能
概述
当前版本 CurveFS 主要具有如下特性：
POSIX 兼容: 像本地文件系统一样使用，业务可以无缝接入
高可扩：元数据集群规模可以线性扩展
高速缓存：客户端有内存和磁盘两级缓存加速
支持数据存储到 S3 接口的对象存储和 CurveBS（开发中）
Client
CurveFS 的 client 通过对接 fuse，实现完整的文件系统功能，称之为 curve-fuse。curve-fuse 支持数据存储在两种后端，分别是 S3 兼容的对象存储和 Curve 块存储中（其他块存储的支持也在计划中），目前已支持 S3 存储后端，存储到 CurveBS 后端尚在完善中，后续还可能支持 S3 和 Curve 块混合存储，让数据根据冷热程度在 S3 与 Curve 块之间流动。curve-fuse 的架构图如下：
curve-fuse 架构图
curve-fuse 包含几个主要模块：
libfuse，对接了其 lowlevel fuse api，支持 fuse 用户态文件系统；
元数据 cache，包含 fsinfo, inode cache, dentry cache, 实现对元数据的缓存；
meta rpc client， 主要对接元数据集群，实现 meta op 的发送，超时重试等功能；
S3 client， 通过对接 S3 接口，将数据存储在 s3 中；
S3 data cache， 这是 S3 数据存储的缓存层，作为数据缓存，加速 S3 数据的读写性能；
curve client 通过对接 Curve 块存储 SDK，实现将数据存储在 Curve 块存储集群中；
volume data cache，这是当数据存储在 Curve 块存储中的缓存层，以加速数据读写性能（开发中）；
curve-fuse 现已对接完整的 fuse 模块，基本实现 POSIX 的兼容，目前 pjdtest 测试通过率 100%。
S3 存储引擎支持
S3 client 负责将文件的读写语义转换成 S3 存储的数据读写（upload，download）语义。考虑到 S3 存储性能较差，我们在这一层对数据做了级缓存：内存缓存（dataCache）和磁盘缓存（diskCache），整体架构如下：
S3ClientAdaptor 主要包含以下几个模块：
FsCacheManager：负责管理整个文件系统的缓存，包括 inode 到 FileCacheManager 的映射、读写 cache 大小统计和控制
FileCacheManager：负责管理单个文件的缓存
ChunkCacheManager：负责单个文件内某个 chunk 的缓存
DataCache：缓存管理的最小粒度，对应一个 chunk 内一段连续的数据空间。数据最终在 DataCache 这一层映射为 S3 存储的一个或多个对象，进行 upoload
diskCache：负责本地磁盘缓存管理，数据持久化可以先写到本地磁盘上，再异步的写到 S3 存储上，能够有效的降低时延，提高吞吐
S3Client：负责调用后端的 S3 存储接口，目前使用的是 AWS 的 SDK
MDS
MDS 是指元数据管理服务，CurveFS 的 MDS 类似于 CurveBS 的 MDS（CurveBS 的 MDS 介绍：https://zhuanlan.zhihu.com/p/333878236），提供中心化的元数据管理服务。
CurveFS 的 MDS 有以下功能：
通过 topology 子模块，管理的整个集群的 topo 信息，以及整个 topo 的生命周期管理
通过 fs 子模块，管理 fs 的 super block 信息；提供文件系统的创建，删除，挂卸载，查询等功能；负责 fs 的 inode、dentry 等元数据在 metaserver 的分布
通过 heartbeat 子模块，维持和 metaserver 的心跳，并收集 metaserver 的状态
通过调度系统进行调度。curvefs 的元数据使用一致性协议保证可靠性，当出现某副本不可用的时候，调度器会自动的进行 recover。调度功能正在开发中
作为一个中心化的元数据管理服务，其性能、可靠性、可用性也十分重要。
在性能上：首先，MDS 上元数据都会全部缓存在内存里，加速其查找。其次，在 fs 创建之后，MDS 会为 fs 分配用来保存 inode、dentry 信息的分片，在系统中，一个分片被称为一个 partition。完成 partition 分配之后，fs 的元数据操作会由 client 直接发向 metaserver。此后的 fs 的 inode、dentry 的元数据管理并不经过 MDS
在可靠性和可用性上：MDS 的元数据持久化到 etcd 中，依靠 3 副本的 etcd 保证元数据的可靠性。可以选择部署多个 MDS 服务，但是同时之后有一个 MDS 对外提供服务，当主 MDS 因为特殊原因挂掉之后，会在自动的在剩下的 MDS 中，通过选主算法选择一个新的主 MDS 继续提供服务
MetaServer
MetaServer 是分布式元数据管理系统，为客户端提供元数据服务。文件系统元数据进行分片管理，每个元数据分片以三副本的形式提供一致性保证，三个副本统称为 Copyset，内部采用 Raft 一致性协议。同时，一个 Copyset 可以管理多个元数据分片。所以，整个文件系统的元数据管理如下所示：
图中共有两个 Copyset，三个副本放置在三台机器上。P1/P2/P3/P4 表示文件系统的元数据分片，其中 P1/P3 属于一个文件系统，P2/P4 属于一个文件系统。
元数据管理
文件系统的元数据进行分片管理，每个分片称为 Partition，Partition 提供了对 dentry 和 inode 的增删改查接口，同时 Partition 管理的元数据全部缓存在内存中。
Inode 对应文件系统中的一个文件或目录，记录相应的元数据信息，比如 atime/ctime/mtime。当 inode 表示一个文件时，还会记录文件的数据寻址信息。每个 Parition 管理固定范围内的 inode，根据 inodeid 进行划分，比如 inodeid [1-200] 由 Partition 1 管理，inodeid [201-400] 由 Partition 2 管理，依次类推。
Dentry 是文件系统中的目录项，记录文件名到 inode 的映射关系。一个父目录下所有文件/目录的 dentry 信息由父目录 inode 所在的 Partition 进行管理。
一致性
文件系统元数据分片以三副本形式存储，利用 raft 算法保证三副本数据的一致性，客户端的元数据请求都由 raft leader 进行处理。在具体实现层面，我们使用了开源的 braft(https://github.com/baidu/braft)，并且一台 server 上可以放置多个复制组，即 multi-raft。
高可靠
高可用的保证主要来自两个方面。首先，raft 算法保证了数据的一致性，同时 raft 心跳机制也可以做到在 raft leader 异常的情况下，复制组内的其余副本可以快速竞选 leader，并对外提供服务。
其次，Raft 基于 Quorum 的一致性协议，在三副本的情况下，只需要两副本存活即可 。但是长时间的两副本运行，对可用性也是一个考验。所以，我们在 Metaserver 与 MDS 之间加入了定时心跳，Metaserver 会定期向 MDS 发送自身的统计信息，比如：内存使用率，磁盘容量，复制组信息等。当某个 Metaserver 进程退出后，复制组信息不再上报给 MDS，此时 MDS 会发现一些复制组只有两副本存活，因此会通过心跳下发 Raft 配置变更请求，尝试将复制组恢复到正常三副本的状态。
全新的部署工具 CurveAdm
为了提升 Curve 的运维便利性，我们设计开发了 CurveAdm 项目，其主要用于部署和管理 Curve 集群，目前已支持部署 CurveFS（CurveBS 的支持正在开发中）。
项目地址：
https://github.com/opencurve/curveadm
CurveFS 部署流程：
https://github.com/opencurve/curveadm#deploy-cluster
CurveAdm 的设计架构如下图所示：
CurveAdm 内嵌一个 SQLite（嵌入式数据库，所有 DB 为一个文件），用于保存集群的 topology 与每个 service 相关信息，包括 serviceId、containerId 等
CurveAdm 通过 SSH 登录目标机器，通过 Docker CLI 执行命令，对容器进行操控，容器所用镜像为 Curve 各个发行版，默认为 latest 最新版本
CurveAdm 与之前的 ansible 部署工具相比较，具有如下几个优点：
CurveAdm 支持跨平台运行，独立打包无其他依赖，可以一键安装，易用性较好
Curve 组件运行在容器里，解决组件依赖问题和发行版适配问题
使用 golang 开发，开发迭代速度快，可定制化程度高
可自助收集集群日志并打包加密上传给 Curve 团队，便于分析解决问题
CurveAdm 本身支持一键自我更新，方便升级
目前已支持功能如下所示：
如果你对 CurveAdm 项目感兴趣，欢迎参与贡献（提交 issue 或需求、开发功能、编写文档等等）。
待解决问题
当前版本是 CurveFS 的第一个 beta 版本，不建议在生产环境使用，已知待解决的问题有：
暂不支持共享读写（开发中）
硬盘数据缓存空间管理策略、流控功能
随机读写性能问题：这是 S3 引擎的特点决定的，我们会进一步优化，比如采用并发分片上传、range 读等
异常节点自动恢复功能（开发中）
回收站功能：误删数据可以找回并恢复
并发读写特性：后续会支持多节点共用文件系统同时读写
监控接入：使用 prometheus 收集监控信息，使用 grafana 进行展示
欢迎在 GitHub 上提交 issue 和 bug，或者添加微信号 opencurve 邀请您入群交流。
后续版本展望
Curve 整体项目的发布节奏通常为每半年一个大版本，每个季度一个小版本，CurveFS 为一个比较大的全新版本，当前首发版本还有很多功能不完备，需要继续完善，下个大版本我们的主要开发目标为（可能会根据实际需求进行部分调整）：
CurveBS 存储引擎支持
数据跨引擎生命周期管理
CSI 插件
部署工具完善
基于 K8s 集群部署：目前已经支持 helm 部署方式，后续将继续优化，支持更高等级的云原生运维级别
多写多读
运维工具优化（监控告警、问题定位）
回收站
HDD 场景适配优化
NFS、S3、HDFS 等兼容性
快照
如果有相关诉求可以与我们沟通交流。
Curve 是什么
Curve 的定位
定位：高性能、易运维、支持广泛场景的开源云原生软件定义存储系统。
愿景：好用的云原生软件定义存储。
CurveBS 介绍
CurveBS 是 Curve 云原生软件定义存储系统的核心组件之一，其具备高性能、高可靠、易运维等特点，可以与云原生场景良好适配实现存算分离架构。CurveFS 后续也会支持使用 CurveBS 作为存储引擎，CurveBS 的总体架构如下图所示：
详细的设计文档可参考往期文章：
http://www.opencurve.io/docs/home/
https://github.com/opencurve/curve#design-documentation
https://github.com/opencurve/curve-meetup-slides
https://zhuanlan.zhihu.com/p/311590077
近期规划
PolarFS 适配：已完成单 pfsd+单 CurveBS 卷的对接，后续会支持多 pfsd+单 CurveBS 卷特性，代码库：https://github.com/skypexu/polardb-file-system/tree/curvebs_sdk_devio
ARM64 平台适配：已完成基本功能测试，后续会进行性能优化和稳定性验证，代码库：https://github.com/opencurve/curve/tree/arm64
FIO CurveBS engine：已支持，代码库：https://github.com/skypexu/fio/tree/nebd_engine
NVME/RDMA 适配：近期会进行适配验证以及性能优化
iSCSI 接口支持：使用范围比较广泛，普适性较高，计划近期支持
Raft 优化：尝试优化 Raft 的日志管理、提升 I/O 并发度、支持 follower 读、Raft 降级（3 副本只有 1 副本存活仍然可对外服务）等
Curve 更多信息详见：
专注数字化转型基础软件研发 2020.07.22 加入
源自网易杭州研究院，是网易数字经济的创新载体和技术孵化器。聚合云计算、大数据、人工智能等新型技术，聚焦研发数据智能、软件研发、基础设施与中间件等基础软件，推动数字化业务发展。
评论