03 04 Curve质量控制 Curve监控体系 Curve运维体系Curve 是网易针对块存储、对象存储、云原生数据库、EC等 多种场景自研的分布式存储系统：  高性能、低延迟  当前实现了高性能块存储，对接OpenStack和 K8s  网易内部线上无故障稳定运行近两年  已完整开源 • github主页： https://opencurve.github.io/ 质量——向用户交付稳定可靠的软件；  监控——直观地展示Curve运行状态；  运维——保障Curve始终稳定高效运行。 质量 ✓ 质量管理体系（设计、开发、review、CI） ✓ 测试方法论（单元测试、集成测试、系统测试） 监控 ✓ 监控架构 ✓ 指标采集、后端处理、可视化展示 运维 ✓ 运维特性 （易部署、易升级、自治） ✓ 运维工具（部署工具、管理工具） 4/33背景 01 02 软件质量的定义是：软件与明确地和隐含地定义的需求相一致的程度。 为了确保最终交付的软件满足需求，必须将质量控制贯穿于设计、开发到测试的整个流程中。 设计  设计流程  文档规范 开发  编码规范与提交流程  版本管理 测试  测试方法论  CI与异常测试 6/33设计流程 Curve团队采用敏捷开发模式，负责人在制定迭代计划时，确认哪些任务需要设计 文档：  小需

新一代分布式存储系统 Curve 李小翠Curve 是高性能、高可用、高可靠的分布式存储系统 • 高性能、低延迟 • 可支撑储场景：块存储、对象存储、云原生数据库、EC等 • 当前实现了高性能块存储，对接OpenStack和 K8s 网易内部线上无故障稳定运行一年多，线上异常演练 • 已开源 • github主页： https://opencurve.github.io/ • github代码仓库： com/opencurve/curve 概述背景 01 02 03 04 总体设计 系统特性 近期规划背景 • 多个存储软件：SDFS、NEFS、NBS • 已有的开源软件：Ceph • 不能胜任性能、延迟敏感的场景 • 异常场景抖动较大（比如慢盘场景） • 去中心节点设计在集群不均衡的情况下需要人工运维 • 基于通用分布式存储构建上层存储服务背景 01 02 03 04 总体设计 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落盘零放大 • 轻量级线性一致性读 • io路径上用户空间零拷贝

Curve核心组件之ChunkServer 查日苏CURVE CURVE是高性能、高可用、高可靠的分布式存储系统 • 高性能、低延迟存储底座 • 可扩展存储场景：块存储、对象存储、云原生数据库、EC等 • 当前实现了高性能块存储，对接 openstack 和 k8s 网易内部线上无故障稳定运行500+天 • 已开源 • github主页： https://opencurve.github https://github.com/opencurve/curveCURVE基本架构 01 02 03 04 ChunkServer架构 ChunkServer核心模块 新版本ChunkServer性能优化CURVE基本架构 • 元数据节点 MDS • 管理和存储元数据信息 • 感知集群状态，合理调度 • 数据节点 Chunkserver • 数据存储 • 副本一致性，raft • 客户端 对元数据增删改查 • 对数据增删改查 • 快照克隆服务器CURVE基本架构 01 02 03 04 ChunkServer架构 ChunkServer核心模块 新版本ChunkServer性能优化Curve ChunkServer是数据节点， 对外提供数据读写和节点管理功 能，底层基于ext4文件系统，操 作实际的磁盘。 ChunkServer架构ChunkServer通过RPC网络层与client，

补充文件空间分配，讨论与确认 背景 调研 开源fs 性能对比 可行性分析 方案对比 对比结论 架构设计 卷和文件系统 元数据架构 文件系统快照 方案一：文件/目录级别快照 方案二：文件系统快照 关键点 元数据设计 数据结构 索引设计 文件空间管理 开发计划及安排 背景 为更好的支持云原生的场景，Curve需要支持高性能通用文件系统，其中高性能主要是适配云原生数据库的场景。当前Curve /27909 性能对比 并对以上文件系统在相同环境进行了元数据节点性能测试： 。测试结果c开发的moosefs和fastcfs元数据性能远优于go开发的chubaofs和c开发的cephfs，理论上分析这个结果是合理的，分布式的元数据设 调研测试 计会涉及到多次rpc的交互。这里需要确认的一点是：我们需要怎样的元数据节点的性能？ 可行性分析 方案对比 根据上述调研和测试结果，我们考虑了三种curvefs的元数据设计方案： 软/硬链接：目前是都不支持的。软链接可以通过标识文件类型解决；由于 prefix + parentid + filename 作为 key , filename 直接和 fileInfo 关联，硬链接无法支持 b. 性能 list：list在通用文件系统中是很常见的操作，目前 curve 的元数据缓存使用的 lru cache，因此 list 只能依赖 etcd 的 range 获取方式。如果需要对 list

orum WARO • 所有副本写成功 • 读可用性高：可以读任一副本 • 写可用性较低，任一副本异常写失败 Quorum • 大多数副本写成功 • 读写服务可用性做一个折中 • 写性能提升，速度取决于写的较快的大多数 W R client W W W client分布式存储介绍 01 存储的发展 | 分布式存储的分类 | 分布式存储的要素 02 03 04 文件系统 -> 块设备层 -> 不同协议/驱动使用中的问题 • io抖动（一致性协议）： 异常场景（比如阵列卡一致性巡检，坏盘，慢盘，网络异常），服务升级 • 性能差（一致性协议）：在通用硬件下，无法支撑数据库、kafka等中间件对存储性能和稳定性要求 • 容量不均衡（数据放置）：集群各节点容量不均衡需要人为干预 • 上述问题和架构涉及、核心功能的选型有关，在已有开源版本上改进代价很大分布式存储介绍 延迟取决于所有副本中最快的大多数主要亮点 高性能 更稳定 跟各 更稳定 具备可视化的开发页面， 直观查看任务运行情况， 数据开发方便，系统运 维方便 易运维 具备可视化的开发页面， 直观查看任务运行情况， 数据开发方便，系统运 维方便 高质量 基于在架构上的选择和优秀的工程实践，Curve 在性能、运维、稳定性、工程实践质量上都优于Ceph主要亮点 — 高性能 测试环境：3台服务器*8块NVME，

Flush流程 FsSync流程 后台流程 poc测试验证 背景 基于s3的daemon版本基于基本的性能测试发现性能非常差。具体数据如下： 通过日志初步分析有2点原因© XXX Page 3 of 9 1.append接口目前采用先从s3 get，在内存中合并完后再put的方式，对s3操作过多 2.对于4k 小io每次都要和s3交互，导致性能非常差。 因此需要通过Cache模块解决以上2个问题。 尽可能的合并后flush到s3上，在读场景上，能够预读1个block大小，减少顺序读对于底层s3的访问频次。从这个思路上该缓存方案主要针对的场景是顺序写和顺序 读，而对于随机写和随机读来说也会有一定性能提升，但效果可能不会太好。 元数据采用2层索引 由于chunk大小是固定的（默认64M），所以Inode中采用map s3ChunkInfoMa 更新元数据，清理DataCache缓存，DataCacheNum_减1。 5.遍历完一轮DataCache后，获取DataCacheNum值，如果不为0，则继续遍历，如果为0则回到1步骤。 poc测试验证 根据上述设计，完成初步daemon，测试结果如下图 目前看写性能有明显的提升，但时延仍然很高， 。 需要进一步分析

Curve⽂件系统性能 ⽹易数帆科技 向东提纲 • 什么是Curve • Curve的应⽤场景及挑战 • Curve客户端⾯临问题及分析 • 什么是ebpf • 基于epbf的Curve Cache设计 • Curve社区介绍Curve是什么？ • Curve云原⽣软件定义存储 • Curve分布式块存储 • Curve分布式⽂件存储 • ⾼性能、易运维、云原⽣Curve⽂件系统框架和主要应⽤场景 的问题 • ⽤户态实现 • 稳定性/可靠性⾼ • 容易更新及维护 • 基于FUSE提供POSIX兼容⽂件接⼝ • 问题 • 相对kernel⽂件系统的实现(ext4, xfs)性能 差异⼤，延迟⾼FUSE⽂件IO读写流程 • 场景1 pytorch example word_language_model • LOOKUP inode 返回 fstat + timeout设置 设置属性 • 关闭⽂件时会发送FLUSH请求和RELEASE请求FUSE⽂件IO读写流程FUSE的IO路径及瓶颈分析 • 对⽐测试 • ⽂件访问测试直接访问ext4 • 通过FUSE访问passthrough_ll底层ext4 • 内核调⽤延迟测试 • 与FUSE Daemon通讯120us左右，FUSE Daemon⼤概10us以内 • 瓶颈在/dev/fuse通讯开销基于FUSE可能的优化点

DPO是disable page out的缩写,FUA是force unit access的缩写 • FUA可以让某些文件系统在做写操作时，不需要提交一个SCSI FLUSH COMMAND，提高性能 • 已经修改TGT，让驱动可以声明自己是否支持DPO & FUA • 由于增加的Curve 驱动没有本地cache，所以DPO & FUA可以turn on. • sd 0:0:0:0: [sda] TGT的性能问题 • 性能问题主要体现在不能有效使用多CPU • 对多个socket connection，在单线程里做event loop多路复用。 • 多个target时，如果挂的设备多，一旦客户端请求量大，就会忙不过来。 • 开源界有尝试修改 • 例如sheepdog的开发者提交过一个patch，但是测试效果不理想，分析 原因，event loop依然是瓶颈对TGT的性能优化 • 管理面是主线程，登录，增、删、改target,lun,session,connection,params 都在主线程，而target epoll 线程也要使用这些数据，多线程冲突，数据一 致性问题就来了对TGT的性能优化（续) • 为每一个target增加一把锁 • Target event loop (TEL)线程和管理面线程使用这把锁互斥 • TEL在运行时锁住这把锁，管理面只能等待，等TEL线程进入epoll

●根据阿里《When Cloud Storage Meets RDMA》的说法 ●在100Gbps网络带宽时，内存带宽成为瓶颈 ●Intel Memory Latency Checker (MLC)测试得到的CPU内存带宽是 61Gbps10/17/22 3 RDMA可以减轻CPU负担 ●可以减少CPU操作网络通讯的开销 ●读写内存都由网卡进行offload ●应用程序不再通过系统调用在内核和用户态来回切换10/17/22 ●PFS支持类POSIX文件的接口，与使用EXT4的存储引擎代码很像， 所以容易移植现有代码到PFS存储引擎 ●CurveBS对文件系统元数据的操作非常少，对文件系统的要求不高， 所以不需要元数据高性能，这方面PFS也合适10/17/22 6 对PFS的修改 ●基于阿里开源的PFS ●不再基于daemon模式，而是直接使用pfs core api ●依然向外提供管理工具, 例如 pfs ls、cp、rm等 ●网络部分依赖内核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

●支持RDMA，TCP，Shared memory等 ●能透明支持多个链路传输，例如多网卡bond ●编译成.so或lib的方式，可以集成到应用程序里 ●有完善的配置功能，ucx_info可以dump配置信息 ●有性能测试工具 ●比较详细的文档2223 UCS ●是一些工具代码，例如 –链表 –hash table –epoll event loop – memory register cache –config ●调用poll(efd)等待有任务执行，然后再调用ucp_worker_progress() ●/dev/cpu_dma_latency 禁止power-saving模式 ●由于rdma速度很快，内核调度时延对性能影响很大。关键应用应开启busy poll。323334 BRPC怎么指定使用UCX?35 修改 BRPC ChannelOptions 增加字段：36 BRPC的Server开启RDMA git –curve主干分支 –ucx_am当前rdma分支 ●对brcp的改动不大，加入的模块基本上独立 ●降低了开发难度 ●ucx满足我们对rdma支持的需求 ●已经测试通过了curve验证，取得了不错的性能提升66 Thank You！