https://opencurve.github.io/ • github代码仓库： https://github.com/opencurve/curveCURVE基本架构 01 02 03 04 Client总体介绍 热升级NEBD总体介绍 新版本Client/NEBD性能优化CURVE基本架构 • 元数据节点 MDS • 管理和存储元数据信息 • 感知集群状态，合理调度 • 数据节点 Chunkserver • 副本一致性，raft • 客户端 Client • 对元数据增删改查 • 对数据增删改查 • 快照克隆服务器CURVE基本架构 01 02 03 04 Client总体介绍 热升级NEBD总体介绍 新版本Client/NEBD性能优化 QEMU、Curve-NBD：上层应用  通过链接curve-client使用curve提供的服务  FileManager：提供接口，记录已挂载卷 02 03 04 Client总体介绍 热升级NEBD总体介绍 新版本Client/NEBD性能优化NEBD 整体介绍 热升级之前，QEMU是直接链接curve-client， 所以client版本需要升级时，需要对QEMU进 程进行重启。NEBD 整体介绍 在QEMU和Curve Client中间加入热升级模块，避 免直接依赖 热升级模块是CS结构：  NEBD Clie

多卷主要亮点 — 易运维 运维场景 Curve Ceph 加盘 对IO无影响 秒级io影响 服务端升级 对IO无影响 重启管控面IO无影响，重启osd io秒级影响 客户端升级 热升级，秒级抖动 不支持热升级，需要业务停服 集群监控 丰富的metric metric类型较少主要亮点 — 更稳定 异常场景 Curve Ceph 坏盘 基本无抖动 无明显抖动 慢盘 io持续抖动，但util未100%

ansible 确认集群 状态 28/33易升级  Client易升级 为避免Curve client升级影响QEMU，Curve Client采用了Client- Server架构，以支持热升级。 升级Curve Client只需重启NEBD Server，业务IO中断时间一般在5 秒之内（右图为1.0版本实测结果）。  MDS易升级 自动化滚动升级——先升备再升主，确保升级过程中只发生一次主

分别从不同场景上进行分析，curve文件系统的元数据应该有以下的操作： 1、系统加载的时候，元数据从持久化介质加载。 2、业务运行过程中，元数据的增删改查。 3、系统退出的时候，元数据持久化。© XXX Page 7 of 24 场景一：系统加载的时候，元数据从持久化介质中加载。 元数据进行恢复的时候，有两种情况。 一种系统必须等到元数据全部加载到内存才能提供服务，这种情况下，元数据需要在内存全缓存。这 能友好，但是需要消耗比较多的内存，元数据服务的扩展性受限于内存，而且在元数据服务启动的 时候，需要等待一段时间加载内存。 一种是元数据需要全部加载到内存，这种情况下，元数据只需要加载一小部分主要的元数据，比如说super block这种，剩下的比如inode，dentry这种，按需加载，而且使用淘汰机制，内存中不常用的元数据可以淘汰出去。这种方式，扩展性好，元数据服务的扩展性不受限于内存，服务上的内存只有几百GB，而硬盘空 盘上读数据，而且在文件系统这种使 用场景下，一次对文件的查找，需要在磁盘上读取多次。 我们的文件系统定位是一个高性能的通用文件系统，元数据的缓存倾向于全缓存。 系统加载的时候从持久化介质中进行加载，需要把一条条持久化的记录加载到内存里。实现把string转化为inode结构体，再插入内存结构中。 场景二：业务运行过程中，元数据的增删改查。 如果采用raft的方式对元数据持久化进行保证

follower从快照恢复，只需要leader把最近一次快照 涉及到chunk数据给到follower，follower再从上次快 照后的日志重放即可。 • chunkserver服务重启，只需要加载快照，然后对 chunk重放快照之后日志即可。 raft snapshot • 用户数据的写入最终转化为对chunk的写入。 • raft的apply，直接在对应的chunk上写入数据。Curve文件存储RAFT应用 处理能力，对磁盘造成很大压力，影响正常IO。 解决思路： chunk支持覆盖写，覆盖写天然是幂等的，写一次和写多次结果一致。 打快照只记录chunk文件的列表，不拷贝chunk的内容。从快照+日志加载数据时，下载的chunk文 件不是打快照的状态，而是最新的状态，回放日志时，把数据重写一遍。Curve对RAFT的优化 优化点二： chunkfile pool 问题背景： Chunkserv

两层映射关系，所有的元数据都缓存在内存中，持久化在 binlog 文件中，binlog采用定期dump的方式删除。基于这种方式的开发： a. 性能 加载：数据量较大的情况下，元数据节点启动较慢；但是元数据使用 master-slave 可以降低 failover 情况下的加载时间 b. 扩展性/可用性/可靠性 扩展性不够，受限于单机的内存和磁盘，只能纵向扩展 可用性足够，由于是 master-slave

空间回收时，根据回收的offset，交给对应的分配器去回收。© XXX Page 7 of 11 文件系统扩容 在线扩容时，直接在新扩容的空间上，创建新的空间分配器进行空间管理。 文件系统重新加载时，再将所有的空间，按照上述的策略，进行分组管理。 接口设计 RPC接口 当前设计是把空间分配器作为内置服务放在元数据节点，所以请求的发起方是fuse client，元数据服务器接收到请求后，

CURVEFS 7 magic number（常量字符 "CURVEFS"），用于标识该文件为 curvefs 元数据持久化文件 version 4 文件版本号（当文件格式变化时，可以 100% 向后兼容加载旧版持久化文件） size 8 键值对数量 key_value_pairs / 键值对（当 size 为 0 时，该字段为空） EOF 1 特殊标记常量 (0XFF)，表示内容已结束 check_sum

erver的ip就可以） 与mds 交互，调用mds接口获取metaserver copyset 和 topo信息，这部分可先不实现（目前先支持单metaserver的情况下，可先不实现，由配置文件加载metaserver的ip） 与metaserver交互, 调用meta server接口获取文件系统元数据信息，调用meta server接口获取文件和目录信息等 与现有块设备client交互，调用块设备接口，对卷进行读写。