乐趣区

关于github:CurveFS预览版重磅首发Curve加速迈向云原生软件定义存储

jiezi

明天，咱们很快乐地公布 Curve 我的项目的文件系统，以及全新的部署工具。这也是 CurveFS 的第一个 beta 版本，预示着在 Curve 社区同仁的共同努力之下，Curve 间隔更好用的云原生软件定义存储又后退了一步。

版本地址：

https://github.com/opencurve/…

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 由三个局部组成：

  1. 客户端 curve-fuse，和元数据集群交互解决文件元数据增删改查申请，和数据集群交互解决文件数据的增删改查申请。

  2. 元数据集群 metaserver cluster，用于接管和解决元数据 (inode 和 dentry) 的增删改查申请。metaserver cluster 的架构和 CurveBS 相似，具备高牢靠、高可用、高可扩的特点：

    MDS 用于治理集群拓扑构造，资源调度。

    metaserver 是数据节点，一个 metaserver 对应治理一个物理磁盘。CurveFS 应用 Raft 保障元数据的可靠性和可用性，Raft 复制组的根本单元是 copyset。一个 metaserver 上蕴含多个 copyset 复制组。

  3. 数据集群 data cluster，用于接管和解决文件数据的增删改查。data cluster 目前反对两存储类型：反对 S3 接口的对象存储以及 CurveBS（开发中）。

次要性能

概述

以后版本 CurveFS 次要具备如下个性：

  1. POSIX 兼容: 像本地文件系统一样应用，业务能够无缝接入
  2. 高可扩：元数据集群规模能够线性扩大
  3. 高速缓存：客户端有内存和磁盘两级缓存减速
  4. 反对数据存储到 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/…），提供中心化的元数据管理服务。

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/…

CurveFS 部署流程：

https://github.com/opencurve/…

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/…

https://github.com/opencurve/…

https://github.com/opencurve/…

https://zhuanlan.zhihu.com/p/…

近期布局

  • PolarFS 适配：已实现单 pfsd+ 单 CurveBS 卷的对接，后续会反对多 pfsd+ 单 CurveBS 卷个性，代码库：https://github.com/skypexu/po…
  • ARM64 平台适配：已实现根本功能测试，后续会进行性能优化和稳定性验证，代码库：https://github.com/opencurve/…
  • FIO CurveBS engine：已反对，代码库：https://github.com/skypexu/fi…
  • NVME/RDMA 适配：近期会进行适配验证以及性能优化
  • iSCSI 接口反对：应用范畴比拟宽泛，普适性较高，打算近期反对
  • Raft 优化：尝试优化 Raft 的日志治理、晋升 I / O 并发度、反对 follower 读、Raft 降级（3 正本只有 1 正本存活依然可对外服务）等

Curve 更多信息详见：

  • Curve 我的项目主页：http://www.opencurve.io/
  • 源码地址：https://github.com/opencurve/…
  • Roadmap：https://github.com/opencurve/…
  • 技术解读合集：https://zhuanlan.zhihu.com/p/…
退出移动版