(SSD)，chunkserver以一块磁盘作为最小的服务单元。TOPOLOGY curve在上物理pool之上又引入逻辑pool的概念，以实现统一存储系统的需求，即在单个存储系统中多副 本PageFile支持块设备、三副本AppendFile（待开发）支持在线对象存储、AppendECFile（待开发）支持 近线对象存储可以共存。 如上所示LogicalPool与pool为多对一的关系，一个物理pool可以存放 文件的元数据以KV的方式存储。 • Key：ParentID + “/”+ BaseName； • Value：自身的文件ID。 这种方式可以很好地平衡几个需求： • 文件列目录：列出目录下的所有文件和目 录 • 文件查找：查找一个具体的文件 • 目录重命名：对一个目录/文件进行重命名 当前元数据信息编码之后存储在 etcd 中。COPYSET Curve系统中数据分片的最小单位称之为Chun 多个节点同时故障的情况下，数据的可靠性会受 到影响。引入CopySet，可提高分布式存储系统中的数据持久性，降低数据丢失的概率。COPYSET ChunkServer，Copyset和Chunk三者之间的关系如下图： Mds在分配空间时，轮流在不同的copyset中分配，每次从copyset中分配1个chunk， 这个chunk用copysetId:chunkId来唯一标识。COPYSET

yset3的三个副本分别在 CS1,CS3,CS4上，完成迁移后，CS1上的副本迁移到CS2上 ① CS1超时未向MDS上报心跳（默认半小时） ② MDS标记CS1状态为offline ③ MDS的recover scheduler发现copyset1, 2, 3的副本CS1 offline， 生成change peer from CS1 to CS2的operator给这三个copyset et ④ MDS通过RPC在CS2上创建copyset1,2,3这三个copyset ⑤ 假定三个copyset的leader都是CS3，在CS3的下一次心跳的 response中，下发第三步生成的三个operator ⑥ CS3收到change peer from CS1 to CS2的operator，给CS2同步 raft日志，当CS2成功赶上进度时，本次raft成员变更成功完成， retired，CS1下线完毕。ChunkServer核心模块-CopysetNode 换盘（CS1对应的盘）后重新上线的流程 初始状态，copyset1，copyset2，copyset3的三个副本分别在 CS2,CS3,CS4上，完成恢复后，CS2上的copyset1,2,3迁移到CS1上 ① CS1换了新盘，并重新格式化后启动chunkserver ② CS1重新向MDS注册 ③

file产生，直接读取chunk file b) 打快照后写过，触发了cow， 有snap file， 合并读取 c) 卷从未写过， 两者都没有，返回NOTEXIST 转储内部快照，即读内部快照的三种情况：克隆总体流程 • 1. 用户发起克隆，生成克隆任务，并持 久化任务元数据到etcd，开始执行克隆 任务。 • 2. 调用mds接口创建clone卷信息，该 clone卷是个临时卷，位于/clone目录下。 • 完成写入后，并标记bitmap，如果全部写过，则取消 clone chunk标记。 异步完成源chunk读到的数据写入到本地 chunk ：欢 迎 大 家 参 与 C U R V E 项 目 ！ • github主页： https://opencurve.github.io/ • github代码仓库： https://github.com/opencurve/curve • 系列讲座：https://space

满足数据库性能要求 • 大io吞吐优化 • muti raft 性能优化 • 开源 • 系列技术分享 • 参与开发人员线上议题讨论会 近期规划欢 迎 大 家 参 与 C U R V E 项 目 ！ • github主页： https://opencurve.github.io/ • github代码仓库： https://github.com/opencurve/curve • 系列讲座：https://space

orker线程，也 存在瓶颈  std::mutex/spinlock 改成 bthread::Mutex  …… 128深度、4K随机写欢 迎 大 家 参 与 C U R V E 项 目 ！  github主页： https://opencurve.github.io/  github代码仓库： https://github.com/opencurve/curve  系列讲座：https://space

--write-out=json revision: 5 3.2.2 举例说明Campagin流程 场景描述：三个mds(mds1, mds2, mds3)，希望实现一个mds作为主提供服务，另外两个mds作为备在主挂掉的时候提供服务的功能。如果利用上述的Campagin进行选举，过程如下： 正常情况： step1: 三个mds向etcdserver写入带有相同前缀的key，etcd会给每个key一个版本号(revision: of 30 异常情况2：EtcdLeader重新进行leader选举，且在该过程中，三个MDS和EtcdServer之间的租约全部失效 step1 MDS2收到Leader/MDS1被删除的通知，MDS3收到Leader/MDS2被删除的通知，Campagin都返回成功 ： 这种情况下自身的key已经不在了，三个MDS都不应该成为leader。 在使用Campagin做选举的时候应该要注意， Page 16 of 30 1. 2. 3. 4.1 Curve中MDS的选举过程 如果对代码部分不感兴趣，请跳到 4.2 图示说明选举流程 MDS使用election模块选有以下三个步骤： 调用Campagin进行选举 如果选举成功，获取一下当前的leaderKey，看是否存在。如果不存在，则继续竞选；如果存在进行下一步 调用Observe观察leader的变化，如果leader有变化，mds退出；重新进行选举

得到一系列可观察的后果，即需要检测的断言·异常自动化测试实践 Robotframework  支持python关键字，灵活定义测试  完善的测试报告  完美兼容Jenkins ci  丰富的第三方库（ssh, paramiko, request等） 用例设计原则  无需绑定特定环境，“随意拉起”  配置化（测试环境、测试负载定义）  控制用例时间（考虑一些折中方案）  Case独立性 SnapshotClone Server HTTP采集 bvar数据 定时获取图表 并发送邮件 获取集群拓扑信息 Curve利用brpc内置的bvar组件生成监控指标，并 使用部署在docker的三个组件进行监控指标的处 理与展示：  Prometheus——面向云原生应用程序的开源 的监控&报警工具，curve利用它进行监控指标 的采集与存储。  Daily reporter——python脚本，定时从

分析这个结果是合理的，分布式的元数据设 调研测试 计会涉及到多次rpc的交互。这里需要确认的一点是：我们需要怎样的元数据节点的性能？ 可行性分析 方案对比 根据上述调研和测试结果，我们考虑了三种curvefs的元数据设计方案： CurveFS kv方案设计 curve实现块设备时，元数据不是扁平化的设计，而是采用来有目录层级的 namespace 方式，namespace 已经实现了 fs curve 的元数据缓存使用的 lru cache，因此 list 只能依赖 etcd 的 range 获取方式。如果需要对 list 加速，需要新的缓存结构 c. 扩展性/可用性/可靠性 依赖于第三方kv存储，目前是etcd CurveFS 单机内存元数据设计 类似 fastcfs 和 moosefs 的元数据设计方式，采用通用的 dentry，inode 两层映射关系，所有的元数据都缓存在内存中，持久化在

文件类型 文件类型标识 文件类型 - 普通文件 d 目录文件 l 符号链接 s 套接字（伪文件） b 块设备（伪文件） c 字符设备（伪文件） p 管道（伪文件） 文件权限 文件权限分为三段：分别对应文件“属主权限”、“属组权限”、“其他用户权限” 权限标识 权限类型 - 无权限 r 读权限4 w 写权限2 x 执行权限1 特殊权限(SUID, SGID, STICKY)© help text ACL的使用规则和原理： ACL是由一系列的Access Entry所组成的，每一条Access Entry定义了特定的类别可以对文件拥有的操作权限。Access Entry有三个组成部分：Entry tag type, qualifier (optional), permission。 # example an Access Entry user:john:rw- group:dev:r--

Curve 分布式存储设计 程义 — Curve Maintainer XAgenda 第二 第三 第四 第一 Curve的由来 Curve的设计目标 Curve块存储 和 Curve文件存储 Curve社区Curve的由来 1. 代码复杂/代码量大 2. 运维难度高 3. 无法满足高的性能需求Curve的设计目标 1. Curve云原生软件定义存储 2. Curve块存储