质量——向用户交付稳定可靠的软件；  监控——直观地展示Curve运行状态；  运维——保障Curve始终稳定高效运行。 质量 ✓ 质量管理体系（设计、开发、review、CI） ✓ 测试方法论（单元测试、集成测试、系统测试） 监控 ✓ 监控架构 ✓ 指标采集、后端处理、可视化展示 运维 ✓ 运维特性 （易部署、易升级、自治） ✓ 运维工具（部署工具、管理工具） 4/33背景 01 02 软件质量的定义是：软件与明确地和隐含地定义的需求相一致的程度。 为了确保最终交付的软件满足需求，必须将质量控制贯穿于设计、开发到测试的整个流程中。 设计  设计流程  文档规范 开发  编码规范与提交流程  版本管理 测试  测试方法论  CI与异常测试 6/33设计流程 Curve团队采用敏捷开发模式，负责人在制定迭代计划时，确认哪些任务需要设计 文档：  小需 Dailybuild测试 提交issue 开发设计 提交PR review +1 CI测试（编译、静态检 查、单元测试、集成测 试、覆盖率80%卡点） 合入master 分支 代码提交流程 异常自动化 测试 混沌测试 （每周一次） CI测试（编译、静态检 查、单元测试、集成测 试、覆盖率80%卡点） 邮件通知 Curve所有代码均在github托管。新 代码需要通过CI测试和code

© XXX Page 1 of 33 CurveFs 用户权限系统调研（已实现）© XXX Page 2 of 33 一、Curvefs测试 1. 启动curvefs 问题1：root用户无法访问挂载目录 测试 allow_root 测试allow_other 参考文献 问题2：本地文件系统挂载默认是共享的？ 问题3：文件系统访问控制是在哪一层实现的？ 二、文件系统权限管理 文件类型 是如何与具体的 Inode 相关联 如何存储和获取ACL信息 Inode权限校验 chmod、chown、setfacl、getfacl接口文件系统自己如何实现 结论： 参考文献： 一、Curvefs测试 代码：https://github.com/cw123/curve/tree/fs_s3_joint_debugging 环境：test2 1. 启动curvefs 手动创建curve卷，/etc/curve/client volume=/fs -o user=test -o conf=./curvefs/conf/curvefs_client.conf /tmp/fsmount 问题1：root用户无法访问挂载目录 测试发现client mount进程是哪个用户启动的就只有该用户(filesystem owner)可以访问该目录，即使挂载点mode是777。 # filesystem owner wanghai0

调研（已实现）© XXX Page 2 of 23 open接口原型 open flags flags定义 flags的含义 libfuse open open flags 在curvefs上的测试 open flags 实现方式 整体flags支持方案 具体flag的实现方案 O_TRUNC I/O模式类 O_DIRECT O_SYNC, O_DSYNC O_NONBLOCK(O_NDELAY open flags flags定义 flags通过宏定义实现，定义见 ，主要包括如下flag fcntl.h # 红色是不支持且会执行结果错误；橙色是暂不确定但不影响写入结果；紫色为暂时无法测试；黑色是已经支持 #define O_RDONLY 00000000 #define O_WRONLY 00000001 #define O_RDWR 00000002 #define O_CREAT handle ino the inode number fi file information© XXX Page 7 of 23 open flags 在curvefs上的测试 在现在的curvefs上进行open相关flag测试，发现已经支持部分open flags（mount 参数指定了default_permissions），VFS做了部分工作（如上open brief所述）： O_CREAT

Ceph（L/N） Curve 151.89% 204.56% 单卷4K随机读写平均延迟(ms) 1.244 3.2 3.1 0.998 4K随机写 4K随机读 61.12 % 67.8% 测试环境：6台服务器*20块SATA SSD，E5-2660 v4，256G，3副本场景 高性能高性能 • quorum机制：raft • 轻量级快照 • io路径上的优化 • filepool落盘零放大 Ceph（L/N） Curve 58.92% 71.21% 10卷4K随机读写平均延迟(ms) 4.34 7 3.7 2.423 4K随机写 4K随机读 38% 34.5% 测试环境：6台服务器*20块SATA SSD，E5-2660 v4，256G，3副本场景高可用 核心组件支持多实例部署，允许部分实例异常 MDS、Snapshotcloneserver 通过 etcd curve_ops_tool • 自动化部署工具 • 一键部署，一键升级高质量 • 良好的模块化和抽象设计 • 完善的测试体系 • 单元测试 行覆盖80%+，分支覆盖70%+ • 集成测试 Given When Then 方法 完备的测试用例集 • 自动化异常测试 41个异常用例 • 自动化大压力随机故障注入 20轮随机故障注入背景 01 02 03 04 总体设计 系统特性

●根据阿里《When Cloud Storage Meets RDMA》的说法 ●在100Gbps网络带宽时，内存带宽成为瓶颈 ●Intel Memory Latency Checker (MLC)测试得到的CPU内存带宽是 61Gbps10/17/22 3 RDMA可以减轻CPU负担 ●可以减少CPU操作网络通讯的开销 ●读写内存都由网卡进行offload ●应用程序不再通过系统调用在内核和用户态来回切换10/17/22 ●网络部分依赖内核tcp，不是零copy10/17/22 18 进展 ●还在测试CurveBS ●布置、监控等工具需要更新10/17/22 19 性能测试 ●使用pfs daemon测试 ●估计非daemon模式的会更快一点，因为没有跨进程开销10/17/22 20 Write,DMA write,Write-zero测试10/17/22 21 fio 4k 1个并发+单深度10/17/22

具备可视化的开发页面， 直观查看任务运行情况， 数据开发方便，系统运 维方便 高质量 基于在架构上的选择和优秀的工程实践，Curve 在性能、运维、稳定性、工程实践质量上都优于Ceph主要亮点 — 高性能 测试环境：3台服务器*8块NVME， Intel(R) Xeon(R) Gold 5318Y CPU @ 2.10GHz ，256G，3副本，使用自带fio 高性能 NVME 块存储场景，Curve随机读写性能远优于Ceph 随着loss增大，还有部分io 随着loss增大，无法进行io 机器宕机 io略微波动 io卡住10s以上 机器卡住 io抖动4s 不可恢复主要亮点 — 高质量 良好的模块化和抽象设计；完善的测试体系 单元测试覆盖率 lines functions link Curve 85.4% 89% curve Ceph 37.1% 43.3% ceph应用情况 Curve 在网易集团内有大规模的生产应用 万个卷，储容量PB级别  网易集团内部业务： • 网易严选，网易云音乐 网易有道，网易游戏 网易Lofter，云信 在集团外有联合开发用户和测试用户  网易外部用户： • 超聚变，创云融达信息技术 • 扬州万方电子技术，思谋科技分布式存储介绍 01 存储的发展 | 分布式存储的分类 | 分布式存储的要素 02 03 04

新版本ChunkServer性能优化新版本ChunkServer性能优化 Curve最新的release1.1中对client和chunkserver分别进行了优化，fio性能测试的结果如下表格： Nbd 10盘： Nbd单盘：新版本ChunkServer性能优化 单深度fio测试chunkserver内部时延统计 Raft 日志落盘延迟 优化前性能分析：braft日志落盘时延占据了ChunkServer处理时延的50% 3、改为O_DIRECT模式 How？ Why？新版本ChunkServer性能优化 1、模拟braft日志落盘方式的demo程序测试结果，latency为调用sync花费的时间（第一次新写，第二次覆盖写）; 2、因为在请求4KB的情况下，写入的大小带上头部后是4120，是不对齐的，所以又测试了一下把写入大小改成4096的情况：新版本ChunkServer性能优化 因此ChunkServer性能优化主要是braft日志落盘优化，包括三个方面：

后台刷数据线程 本地磁盘缓存 关键数据结构 详细设计 Write流程 Read流程 ReleaseCache流程 Flush流程 FsSync流程 后台流程 poc测试验证 背景 基于s3的daemon版本基于基本的性能测试发现性能非常差。具体数据如下： 通过日志初步分析有2点原因© XXX Page 3 of 9 1.append接口目前采用先从s3 get，在内存中合并完后再put的方式，对s3操作过多 更新元数据，清理DataCache缓存，DataCacheNum_减1。 5.遍历完一轮DataCache后，获取DataCacheNum值，如果不为0，则继续遍历，如果为0则回到1步骤。 poc测试验证 根据上述设计，完成初步daemon，测试结果如下图 目前看写性能有明显的提升，但时延仍然很高， 。 需要进一步分析

并对以上文件系统在相同环境进行了元数据节点性能测试： 。测试结果c开发的moosefs和fastcfs元数据性能远优于go开发的chubaofs和c开发的cephfs，理论上分析这个结果是合理的，分布式的元数据设 调研测试 计会涉及到多次rpc的交互。这里需要确认的一点是：我们需要怎样的元数据节点的性能？ 可行性分析 方案对比 根据上述调研和测试结果，我们考虑了三种curvefs的元数据设计方案：

设置属性 • 关闭⽂件时会发送FLUSH请求和RELEASE请求FUSE⽂件IO读写流程FUSE的IO路径及瓶颈分析 • 对⽐测试 • ⽂件访问测试直接访问ext4 • 通过FUSE访问passthrough_ll底层ext4 • 内核调⽤延迟测试 • 与FUSE Daemon通讯120us左右，FUSE Daemon⼤概10us以内 • 瓶颈在/dev/fuse通讯开销基于FUSE可能的优化点