Curve版本更新录(202x)
2022-07-24 17:30:19 阿炯

本文是从Curve的产品主页分离出来的,专门用于该软件的更新记录,截止到2029年12月31日。

最新版本:2.3
为了能让用户使用到稳定可靠的 Curve 存储系统,在 v2.2.0 版本的基础上,进行了全方位的常规功能测试、混沌测试、性能测试、压力测试、长期稳定性测试等工作,并且将 CurveFS 文件存储上线到网易内部业务生产环境,经过一段时间的稳定运行考验后于2022年7月下旬发布了 v2.3.0 版本。

重点增强

v2.3.0 版本相比上个版本主要新增了共享文件存储服务能力,另外块存储服务方面也有如下增强:
io 路径上去掉一次 io 落盘,提升 io 性能,在 4k 随机写场景下有 100% 性能提升;
在块设备层面支持卷的读写权限控制;

与 CurveFS-v0.1.0 版比较,v2.3.0 在共享文件存储服务方面新增了如下重要能力:
支持多挂载
支持 close-to-open 数据一致性
支持 CurveBS 后端
支持元数据 rocksdb 持久化
支持 rename 事务化
支持元数据集群自动化调度

性能:open、du、stat、ls 等元数据操作性能优化;s3 后端缓存满的情况下数据性能优化

监控:全链路 metric 完善;提供 grafana+promethues 一件部署脚本

适用场景:基于 v2.3.0 版本在网易内部与多个业务团队进行了联合测试,也与竞品进行了对比测试,Curve 表现较好,已有部分业务在生产环境落地使用,下面简单介绍下相关业务的测试场景和 Curve 表现,同时也欢迎广大 Curve 社区小伙伴探索更多适用场景。

AI 训练

场景简述:受限于硬件条件,基于 CPU 做了简单的单训练节点对比测试。使用 ImageNet-2012 数据集,resnet50 模型,商汤的训练框架进行训练,分别在本地盘,CurveFS,CephFS 上做了对比测试。测试对比数据:取第一个 epoch 中 1000 轮 iter 的训练时间做对比,数据如下:
文件系统     本地文件系统 ext4     CurveFS     CephFS
1000 轮 iter 的训练时间     37mins     54mins     127mins

CurveFS 得益于缓存盘的优势,性能优于 CephFS,但由于当前的 lru 缓存策略,CurveFS 的性能低于本地盘。

下一步计划:AI 场景用户涉及到的 IO 流程主要体现在:数据集制作(数据导入)、数据集元数据信息提取(ls -R 获取元数据信息)、数据集训练(写少读多)。后续 CurveFS 会在这几个方面做针对性的优化:
提高小文件并发写的吞吐;
优化元数据操作 ls -R 的性能;
支持目录、文件的预读功能;

数据备份

场景简述:网易内部有大量的 GitLab 代码库、数据库等的数据备份需求,此类场景的需求非常简单,业务最关注的是单位存储成本,对 IOPS、时延等性能要求不高,对大文件写入读取的吞吐带宽比较关注,对数据可靠性要求比较高。

对象存储通常有标准、低频、归档、冷归档等存储类型,费用依次降低,但归档和冷归档存储中的数据需要先解冻才能访问。因此我们将业务备份的数据保存到对象存储系统的低频存储中,进一步节省备份数据的存储成本。

测试对比数据:原有的备份系统通常是 RAID10 + 运维自建 NFS 服务方案,RAID10 是 2 倍的数据冗余,低频存储通常使用 EC 纠删码存储数据,可以将备份数据的冗余度从 2 倍降低到 1.2 倍左右,使用 Curve 共享文件存储系统可节省 40% 的存储空间,同时也免去了业务自行运维 NFS 的麻烦。

下一步计划:
继续优化大文件吞吐;
集团内部业务推广;
支持将访问频次极低的数据存储到归档存储中,进一步降低备份数据的存储成本;

ES 冷数据存储

场景简述:据了解,由于 ES 的历史数据量通常很大,占用存储资源较多,为了节约存储成本,原有的 ES 冷数存储方案有 2 种:
将 n 月以上的冷数据导出备份到 RAID 盘上(一般数据冗余比例为 2);历史数据查询流程很长,要先将备份数据读取上来进行恢复后才能查询;
另外一种方案是 ES 计算节点和存储节点混部,ES 应用层利用数据生命周期管理功能对冷数据进行不同的存储介质和副本数配置,但一般存储容量是瓶颈导致服务器浪费严重;

而使用 Curve 共享文件存储作为保存 elastic search 的冷数据,数据存储在集团内部对象存储服务中,使用的是低频存储形态(冗余副本比例为 1.2)以便进一步降低单位存储成本。ES 节点上使用 curve-fuse 挂载文件系统(也可配置一块本地缓存盘进一步提升吞吐)即可开箱即用,不再需要考虑备份数据的恢复、本地文件系统容量问题和运维问题,只需要最小规模的计算节点即可(并且可以随时弹性伸缩),非常的方便。

测试对比数据:性能指标完全可以满足冷数据需求,因此重点关注成本对比情况,经测算,第一种部署方案情况下可以节省 40% 的存储空间,同时也免去了业务自行运维存储系统的麻烦;第二种方案则可以节省大量的服务器资源和运维人力,成本节省更明显,以我们对接的业务为例,共 800TB 冷数据,2 副本,单盘 8T,每台服务器 10 块盘,考虑到集群水位和硬盘实际可用空间,共需要 28 台服务器,而使用 Curve 共享存储系统后,可以节约成本超 100 万(包含所有 Curve 所需资源和 ES 冷数据所需计算节点资源)。

下一步计划:继续优化小文件吞吐

性能测试

性能测试数据
Curve 共享文件存储 + 对象存储数据后端场景下的性能已经处于开源存储系统领先水平,后续版本我们还会继续优化,为 Curve 社区提供更高性能的云原生存储系统。

性能相关参数配置
配置项 所属配置文件/进程 说明

fuseClient.enableMultiMountPointRename

curve-fuse 进程
curvefs/conf/client.conf

在不需要对同一文件系统多挂载并发rename场景可以设置该配置项为false来提高元数据性能,默认为false。

braft.raft_sync

curvefs-metaserver 进程
curvefs/conf/metaserver.conf

每次写raft wal 是否sync,默认为false,只在close时sync,用于保证更高的元数据性能。但在三副本同时掉电的情况下存在数据丢失的可能,若要保证该情况下的数据可靠性则需要设置为true。

s3.async_thread_num;s3.max_connections;

curve-fuse 进程

curvefs/conf/client.conf

AWS S3 C++ SDK使用这两个参数来实现多线程,但是线程是同步的,如果每个请求后端处理时间为10ms,那么一个线程1秒最多可以处理100个请求,n个线程最多可处理100*n个请求,调大这两个参数可以提升吞吐带宽(两个参数值配置为相同值即可)


其他重要配置
配置项 所属配置文件/进程 说明
fuseClient.cto

curve-fuse 进程

curvefs/conf/client.conf

在多挂载情况下,默认为false。请根据业务需要确定是否开启cto。
diskCache.maxUsableSpaceBytes

 

curve-fuse 进程

curvefs/conf/client.conf

缓存盘大小,默认200GB。请根据缓存盘的实际大小进行配置。

enableSumInDir

curvefs 工具

curvefs/conf/tools.conf

统计xattr中的信息,可以加速du。该选项打开后不支持硬链接。


将为以上小伙伴提供 Curve 社区周边大礼包~也欢迎更多小伙伴参与到 Curve 开源社区,不仅是提交代码,还可以讨论需求、交流建议、反馈问题、完善文档、分享落地实践等。

后续版本规划
后续版本将持续提升 Curve 块存储和共享文件存储性能,并增强 Curve 共享文件存储的功能,下个大版本规划的主要功能有:
块存储:支持 NVMe 场景下的 SPDK 能力,升级替换块存储的 ext4 引擎;
共享文件存储:
支持数据预热功能;
支持使用 Curve 块存储集群作为高性能数据存储后端并支持生产环境使用;
支持冷热数据分层存储和数据生命周期管理;
支持文件回收站、文件系统配额功能;