•服务质量要求：数据不能丢、服务随时可用、弹性扩缩容 要什么 •成百上千台存储节点 •磁盘故障、机器故障、网络故障概率性发生 有什么 分布式存储系统需要满足接口需求，并且有持续监控、错误检测、容错与自动恢复的能力 以达到高可靠、高可用、高可扩分布式存储的要素 要 素 拆 解 数据分布 —— 无中心节点/中心节点 均 衡 地址空间的每段数据会分布在不同机器的磁盘上，如 d等 • 强一致性协议对异常的容忍较差 使用WARO一致性协议 • 所有副本写完成返回客户端 • 延迟取决于所有副本中最慢的那一个块存储场景 为云主机提供云盘，云盘提供随机读写、快照（数据备份，灾备使用）、镜像（模板，自定义）功能。块存储场景 为物理机提供块设备 Linux IO栈 应用程序 -> 文件系统 -> 块设备层 -> 不同协议/驱动使用中的问题 • io抖动（一致性协议）： io持续抖动，但util未100% io持续抖动，util持续100% 网络丢包 随着loss增大，还有部分io 随着loss增大，无法进行io 机器宕机 io略微波动 io卡住10s以上 机器卡住 io抖动4s 不可恢复主要亮点 — 高质量 良好的模块化和抽象设计；完善的测试体系 单元测试覆盖率 lines functions link Curve 85.4% 89% curve Ceph 37.1% 43

易部署 • 批量配置、批量部署 • 操作简单 易升级 • 客户端采用CS架构，升级只需重启服务，秒级影响 • MDS与ChunkServer支持滚动升级 自治 • 自动均衡 • 自动故障恢复 27/33易部署 准备安装 包 配置用户 配置SSH 免密 安装 ansible 配置Ansible 执行 ansible 确认集群 状态 28/33易升级  Client易升级 MDS易升级 自动化滚动升级——先升备再升主，确保升级过程中只发生一次主 备切换。  ChunkServer易升级 自动化滚动升级——升级一个zone的所有ChunkServer后，等待集 群恢复健康后，自动升级下一个zone的ChunkServer；以避免升级 时一个copyset中多个ChunkServer离线，导致业务IO挂起。 重启NEBD Server 29/33自动均衡 各ChunkServer上全部copyset，其副本分布的 ChunkServer总数量均衡。 30/33网络丢包10% 自动故障恢复 Curve可在多种软硬件故障场景（如单mds故障、单ChunkServer故障、硬盘故障、网络丢包等） 实现自动恢复，保障存储服务高可用性。  多对多，恢复时间短  精确的流量控制，对io影响很小 Kill一个节点所有ChunkServer进程 31/33快照克隆工具snaptool

对元数据增删改查 • 对数据增删改查 • 快照克隆服务器 • 快照 • 克隆快照和克隆的特点 • 快照的定义 快照是云盘数据在某个时刻完整的只读拷贝，是一种便捷高效的数据容灾手段， 常用于数据备份、制作自定义镜像、应用容灾等。 • 快照的特点 • 转储到s3对象存储 • 异步转储快照，底层使用copy-on-write技术，读写不影响转储 • 增量转储，第一次全量转储s3之后，后续只需转储增量部分

这种情况是常态，大概率情况ElectionTime略大于ElectionTimeout, LeaseTime >= 1.5*ElectionTimeout > ElectionTime 这种情况下etcd集群恢复正常之后，MDS与etcd集群的lease维持正常；定期get Leader/MDS1正常；Observe正常 4.2.4 异常情况3：Etcd的leader发生重新选举，MDS1受到影响退出，不一定可以正常处理。 GetTimeout < ElectionTime 4.2.4.1 LeaseTIme < ElectionTime的情况 这种情况发生概率较小，etcd集群选出新leader耗时较长 当etcd集群恢复正常的情况下，MDS1的lease已过期，etcd server把MDS1注册过来的Key删掉© XXX Page 22 of 30 2. 1. 此时会有两件事情发生, 顺序不定： 一是MDS1定期去get 这种情况下出现双主的最长时间为PeriodicGetTime(蓝色直线段)， 短暂时间内的双主情况是可以接受的。 4.2.4.2 GetTimeout < ElectionTime 当etcd集群恢复正常的情况下，MDS1的lease没有过期，但是get Leader/MDS1超时。© XXX Page 23 of 30 1. 2. MDS1会退出，但lease的最短过期时间为0，最长过期时间为LeaseTIme

这种方式相当于每次都是全量缓存当前元数据，不做增量快照，考虑到转储逻辑，这也是可以接受的 对比这两种方案，第一种方案对于copy场景是友好的，但需要重新实现一套快照逻辑；第二种方案的改动和实现相对简单，并且对于需要备份的场景也是够用的。从可解决程度和解决的必要性考虑，选择第二种方 案。 关键点 mds volume 文件空间管理 文件系统的元数据所在的copyset分配策略（前期可以考虑都分配到同一个copyset上）

副本数量调度器。根据当前copyset的副本数生成副本增删任务； RecoverScheduler: 恢复调度器。根据当前copyset副本的存活状态生成迁移任务。 结论：心跳参考curve。目前这些调度器在curvefs第一阶段不用全部实现。所有和均衡相关的，暂时不做。只做和故障处理相关的副本补全恢复的调度。 6、详细设计 6.1 创建fs curvefs管理工具发起创建fs命令，mds收到 带上copyset信息。 7.2 mds端 1、需要实现topo模块 2、实现mds和metaserver的心跳 3、实现fs和copyset的分片策略的实现 4、实现出现异常场景下的数据恢复，副本修复的调度。 7.3 metaserver端 1、需要提供copyset的创建功能 2、由copyset负责inode和dentry的管理 3、定期向mds上报心跳，并根据心跳结果执行配置变更

MDS、Snapshotcloneserver 通过 etcd 选主，实现高可用高可用 chunkserver 使用raft，2N + 1 个副本允许 N 副本异常自治 • 自动故障恢复 • 多对多，恢复时间短 • 精确的流量控制，对io几乎无影响自治 • 集群负载和资源均衡 • leader copyset scatter-width • 无需人工干预 • 对io影响几乎无影响易运维

rver核心模块-CopysetNode 换盘（CS1对应的盘）后重新上线的流程 初始状态，copyset1，copyset2，copyset3的三个副本分别在 CS2,CS3,CS4上，完成恢复后，CS2上的copyset1,2,3迁移到CS1上 ① CS1换了新盘，并重新格式化后启动chunkserver ② CS1重新向MDS注册 ③ MDS生成新的chunkserver id和token给CS1 raft日志，当CS1成功赶上进度时，本次raft成员变更成功完成， CS1成为了复制组的一员， CS2不再属于这个复制组。 ⑧ CS3在下一次心跳中向MDS报告本次raft成员变更已完成 ⑨ 等CS1上的copyset数量恢复到和其它节点相差不大时，集群回 到均衡状态，迁移结束ChunkServer核心模块-DataStore ChunkServer的目录结构： • 每个copyset一个目录，后面三个目录由bra

以链接库的形式提供给QEMU使用  NEBD Server(part2)：将NEBD Client的请求转 发到Curve Client 升级过程只需要重启NEBD Server即可，IO可在 1~5s内恢复NEBD 整体介绍CURVE基本架构 01 02 03 04 Client总体介绍 热升级NEBD总体介绍 新版本Client/NEBD性能优化NEBD性能优化 场景：fio 128深度、4K随机写

由于chunk可以覆盖写，所以chunk的写入天然具有幂 等性。 • 对chunk打快照不需要把chunk重新换个地方复制一遍， 只需要记录下chunk文件的list。 • follower从快照恢复，只需要leader把最近一次快照 涉及到chunk数据给到follower，follower再从上次快 照后的日志重放即可。 • chunkserver服务重启，只需要加载快照，然后对 chunk重放快照之后日志即可。