软件质量的定义是：软件与明确地和隐含地定义的需求相一致的程度。 为了确保最终交付的软件满足需求，必须将质量控制贯穿于设计、开发到测试的整个流程中。 设计  设计流程  文档规范 开发  编码规范与提交流程  版本管理 测试  测试方法论  CI与异常测试 6/33设计流程 Curve团队采用敏捷开发模式，负责人在制定迭代计划时，确认哪些任务需要设计 文档：  小 Case通用性（兼顾curve、ceph等）  Tag规范(优先级、版本、运行时间)  最大化覆盖率（打乱操作顺序、随机 sleep）  精确性（checkpoint）  稳定性（避免环境因素、其他模块干扰） Curve使用Robotframework框架进行异常自动化测试， 相关代码见curve/robot at opencurve/curve (github.com) 17/33CI测试与异常测试报表 27/33易部署 准备安装 包 配置用户 配置SSH 免密 安装 ansible 配置Ansible 执行 ansible 确认集群 状态 28/33易升级  Client易升级 为避免Curve client升级影响QEMU，Curve Client采用了Client- Server架构，以支持热升级。 升级Curve Client只需重启NEBD Server，业务IO中断时间一般在5

提供命令在多个节点之间有序复制和执行，当多个节 点初始状态一致的时候，保证节点之间状态一致。 raft日志复制RAFT协议简介 raft配置变更 • 配置：加入一致性算法的服务器集合。 • 集群的配置不可避免会发生变更，比如替换宕机的机器。 直接配置变更可能出现双主问题 • 共同一致（joint consensus） • 集群先切换到一个过渡的配置(old + new)，一旦共同一 致已经被提交， 存写入文件的数据。Curve文件存储RAFT应用 基于rocksdb的存储引擎 • 要求存储的元数据的大小不超过内存的大小 • raft apply的请求，数据都在内存，直接修改 内存中的数据 • raft snapshot，为避免快照对正常操作的影 响，利用操作系统的内存写时复制技术， fork一个进程创建完整的状态机的内存快照， 后台遍历内存，把内存的数据持久化到本地 磁盘 基于memory的存储引擎 • 存储元数据量不受内存大小限制 (a(leader), b, c) -> (a, b(leader) , c) 每个chunkserver上的leader copyset个数尽 量均衡。 • RapidLeaderScheduler 手动执行，快速leader均衡。 用于新建集群、扩容集群、升级服务等场景CURVE的均衡效果Curve介绍 01 02 raft和braft 03 raft在Curve中的应用 05 Q&A

一、Curvefs测试 代码：https://github.com/cw123/curve/tree/fs_s3_joint_debugging 环境：test2 1. 启动curvefs 手动创建curve卷，/etc/curve/client.conf中配置卷所在集群信息。 启动服务&client挂载卷：bash startfs.sh start volume (挂载目录为/tmp/fsmount)© 还需要在/etc/fuse.conf中增加配置项‘user_allow_other’）启用内核基于mode的权限控制。 2：新建rootinode mode = 1777（原因是设置STICKY，避免普通用户对非自己所属文件的删除） 3：这样达到的效果除了不支持ACL外与正常本地文件系统权限管理一致（一般情况下使用ACL极少，且从抓取的传媒接口调用发现并未涉及相关接口的调用）。 参考文献：

1、inode、entry 的编码 2、KVStore Q&A 单靠 redis 的 AOF 机制能否保证数据不丢失? redis 的高可用、高可扩方案？ redis + muliraft 存在的问题？ redis 改造 vs 自己实现? redis 中哈希表实现的优点？ 参考 前言 根据之前讨论的结果，元数据节点的架构如下图所示，这里涉及到两部分需要持久化/编码的内容： Raft Log：记录 DEL 操作时，value_length 和 value 则为空 key_length 4 key 长度 key $key_length 编码后的 key [value_length] 4 value 长度 [value] $value_length 编码后的 value checksum 8 前面 5 部分的校验和© XXX Page 4 of 12 Raft Snapshot +- $key_length 保存编码后的 key value_length 4 value 长度 value $value_length 保存编码后的 value© XXX Page 5 of 12 其他说明 持久化文件中涉及到的数字均以小端序存储 利用 fork 子进程 (COW) 的方式解决在持久化的过程中，读写冲突的问题以及性能问题 实现 1、inode、entry 的编码 给 inode、dentry

这个metanode的的处理能力。通过合理的配置copyset的能力的，应该的可以避免一个机器上，有太多的copyset。 结论：coypset由fs共用。具体的使用上，每一个copyset上，有一个可以由多少fs共用的限制。这个限制通过配置文件进行配置。用户挂载时可以通过参数配置是否独占copyset。原因是，为了避免fs独占copyset 带来的copyset数量过多影响性能的问题。 3.3 copyset个数是否可以动态调整？ 可以采用hash的方式去确定inode的分片。比如说， ， copysetid = (fsid + inodeid << shift ) % totalCopysetNum 如果采用hash方案，扩容按照pool扩容，避免hash带来的数据迁移。用这种方式简化处理，改变hash映射方式带来的数据迁移，在技术实现上难度应该很大，暂时不考虑。 还有一种方式是chubaofs方案，在文件系统初始化的时候，初始化少数cop

因此ChunkServer性能优化主要是braft日志落盘优化，包括三个方面： 1. 追加写改为覆盖写（避免每次写的时候改变元数据，减少IO放大） 2. 写入时4KB对齐（4KB不对齐的情况下，每次写入都会有读请求，从而影响效率） 3. 改为O_DIRECT模式（改为Direct模式可以避免显式调用sync）欢 迎 大 家 参 与 C U R V E 项 目 ！ • github主页： https://opencurve

Value：自身的文件ID。 这种方式可以很好地平衡几个需求： • 文件列目录：列出目录下的所有文件和目 录 • 文件查找：查找一个具体的文件 • 目录重命名：对一个目录/文件进行重命名 当前元数据信息编码之后存储在 etcd 中。COPYSET Curve系统中数据分片的最小单位称之为Chunk。在大规模的存储容量下，会产生大量的Chunk，如此众多的 Chunk，会对元数据的存储、管理产生一定

IOBuf DMA ●修改BRPC，允许使用dpdk内存作为IOBuf的内存分配器 ●BRPC接收到的数据在IOBuf中，IOBuf直接使用于NVME DMA传输 ●使用IOBuf内存读nvme，避免自己写PRP页面对齐内存分配代码10/17/22 11 pfs_pwrite_zero ●在初始化curvebs时，需要创建chunk pool, 每一个chunk都要填零 ●chunk不再被卷使用时，需要回归chunk

明底层Chunkserver正在处理的 请求数量过多。按照一般重试逻辑，大概率情况下重试请求还是返回OVERLOAD，造成用户IO请求一直 无法返回。 加入睡眠时间指数退避，并加入一个随机值，避免sleep后大量重试又碰撞到一起。 RPC超时： 请求在chunkserver端处理请求处理时间长，导致请求的返回时间超过了预期的RPC超时时间。 这种情况下，如果重试请求的RPC超时时间不发

件处理，可以参考如下策略，大小文件阈值为1MiB：© XXX Page 6 of 11 并发问题 如果所有的空间分配和回收全部由一个分配器来进行管理，那么这里的分配很有可能成为一个瓶颈。 为了避免整个问题，可以将整个空间，由多个分配器来进行管理，每个分配器管理不同的地址空间。比如，将整个空间划分为10组，每组空间都有一个空间分配器进行管理。 在申请空间时，如果没有附带期望地址空间的offs