r a f t 在 C u r v e 存 储 中 的 工 程 实 践 陈威Curve介绍 01 02 raft和braft 03 raft在Curve中的应用 05 Q&A 04 Curve对raft的优化项目背景 Curve是一个 高性能、更稳定、易运维 的 云原生 分布式存储系统，支持 块存储 和 文件存储 2018~2021 Curve块存储 2021~2022 Curve文件存储 • 稳定性挑战 • 算力平台kubernetes的迅速发展 • AI/大数据业务的快速增长 • 存储使用Ceph文件存储/HDFS • 成本/性能挑战 Curve块存储和文件存储均采用raft协议整体架构 • 对接OpenStack平台为云主机提供高性能块 存储服务 • 对接Kubernetes为其提供RWO、RWX等类 型的持久化存储卷 • 对接PolarFS作为云原生数据库的高性能存储 开发者 操作系统 芯片 数据库 云原生 AI训练 大数据 社区生态Curve介绍 01 02 raft和braft 03 raft在Curve中的应用 05 Q&A 04 Curve对raft的优化RAFT协议简介 什么是raft • raft 是一种新型易于理解的分布式一致性复制协议，由斯坦福大学的Diego Ongaro和John Ousterhout提出，《In Search

pgbench 延迟降低21% TPS提升26% 研究现状Curve块存储 1. 分布式块存储服务 2. KVM块存储服务 3. iSCSI协议 4. 容器云块存储(CSI) 应用场景Curve块存储 1. 高可用性/高可靠性 (易运维) 2. RAFT一致性协议 3. CopySet分配算法 4. 拓扑结构 5. 高性能 6. chunkfilepool (降低写放大) 7. data chunkserver按照故障域分组 4. copyset中的节点属于不同的 故障域 数据组织Curve块存储 IO流程Curve块存储 1. chunkserver负责数据的存储 2. RAFT协议保持数据的一致 性 3. chunkfile pool降低元数据开 销 Chunkserver服务Curve块存储 性能设计Curve块存储 在线升级设计 1. 客户端分成NebdClient与 性能 1. 完善RDMA/SPDK方案，发布稳定版本 2. 更高性能硬件选型、适配及性能调优 3. 大文件读写性能优化，RAFT优化，降低写放大 3. 功能 1. 文件存储支持回收站/生命周期管理/配额/用户权限等 2. 支持NFS、CIFS/SMB、HDFS等协议 3. 块存储支持按存储池创建卷Curve 社区介绍 1. Curve的成长离不开社区贡献者的支持和参与。非常欢迎广大

新版本ChunkServer性能优化CURVE基本架构 • 元数据节点 MDS • 管理和存储元数据信息 • 感知集群状态，合理调度 • 数据节点 Chunkserver • 数据存储 • 副本一致性，raft • 客户端 Client • 对元数据增删改查 • 对数据增删改查 • 快照克隆服务器CURVE基本架构 01 02 03 04 ChunkServer架构 ChunkServer核心模块 括读写socket，rpc协议解析等。 ChunkServer架构RPC Service层是对外提供的一些RPC服 务的接口。包含的RPC服务有： • ChunkService。IO相关操作 • CliService。成员变更相关操作 • CopySetService。创建copyset等操 作 • RaftService。Braft内置的service， 完成raft成员之间的选举，日志复制， 实现了braft的状态机，完成与raft的交 互。详细交互流程后面展开。 CopysetNodeManager负责管理 CopysetNode的创建、初始化、删除等 ChunkServer架构心跳模块有两方面的职责： 1、向MDS节点上报心跳，心跳中包括 ChunkServer本身的一些统计信息 2、解析MDS的心跳response中的raft 成员变更信息，向CopysetNode发起变

这个在inode的ExtentsTree字段 meta partition(raft group) Btree、B+ tree 好 有 tiny extent，多个文件共用 normal extent，属于一个文件 partition append→ master slave协议 overwrite → raft 更适合大文件顺序写 fastcfs 有元数据服务器 inode和dentry放一个结构体。 parent inode + name) segment kv → hashtable(key inode + offset) etcd 差 块设备，最小10GB segment + chunk raft 块设备的元数据管理 cephfs 3、各内存结构体 时间复杂度 空间复杂度 特点 可用实现 Btree 一个节点上保存多条数据，减少 系统加载的时候从持久化介质中进行加载，需要把一条条持久化的记录加载到内存里。实现把string转化为inode结构体，再插入内存结构中。 场景二：业务运行过程中，元数据的增删改查。 如果采用raft的方式对元数据持久化进行保证，所有元数据的处理都是先写WAL，再修改内存结构。那么任何对元数据的增删改查，对应着一条记录，根据记录去修改内存数据。 按照之前的讨论，curve文件系统的元数据管理

8、inode和dentry的内存估算 8.1 一台机器上能存放多少个inode和dentry 8.2 一台机器上建议的copyset数量 8.3 每个copyset建议管理存储容量的大小 1、背景 curvefs使用raft作为元数据一致性的保证。为了提高元数据的可扩展性和并发处理能力，采用元数据分片的方式管理inode和dentry的元数据。inode的分片依据是fsid + inodeid，dentry的分片依据是fsid 这里需要重新考虑curvefs的copyset和fs的元数据分片的对应关系。© XXX Page 3 of 19 2、chubaofs的元数据管理 chubaofs（补充链接）的元数据也是采用的raft的方式进行管理，可以借鉴一下chubaofs的元数据的分片策略。 通过分析chubaofs的源代码。chubaofs的用volume管理一个文件系统，每个volume有若干meta partition和data 3、定期向mds上报心跳，并根据心跳结果执行配置变更 metaserver 子模块拆分 metaserver service：接受rpc请求 copyset：负责对元数据的持久化，主要是一致性协议raft的处理© XXX Page 18 of 19 metastore：负责元数据的内存部分的管理，负责选partition partition：负责元数据的一段分片，每个元数据一定有对应的partition进行处理

TGT 服务器的优化块设备协议 • NBD • Linux专有块设备协议 • iSCSI • 广泛支持的外部设备协议（块，磁带等）Curve云原生存储支持块设备 • 通过NBD，只支持Linux • 通过SDK API，目前只支持Linux • PFS • 扩大使用范围 • 通过iSCSI支持更多系统，例如Windows, 类UNIX系统等，使用两项基础 技术 • TCP/IP TCP/IP • SCSI • 替代SAN • 可靠性、稳定性方面有自己的的特色，使用raft副本一致性和copyset概念可以自动 修复损坏的副本，并且可扩容。无论在可靠性、稳定性还是性价比方面都很有优势， 使用廉价硬件搭建。iSCSI软件 • Client端: iscsi initiator，系统自带 • Linux open-iscsi • Windows iSCSI 发起者 • 服务器端 target服务器 • LINUX LILO • 一般用于输出内核本地块设备 • TCMU • 作为LILO支持用户态的接口 • 如何评价LILO • 输出内核块设备I/O效率高 • 不利于把复杂的存储协议代码搬进内核，例如(curve, brpc, c++, protobuf 等) • TCMU多了一层转接，配置过程复杂，业界踩的坑不够多。 • TCMU的用户态代码会受到框架约束，不够灵活。iSCSI

05 克隆的实现CURVE基本架构 • 元数据节点 MDS • 管理和存储元数据信息 • 感知集群状态，合理调度 • 数据节点 Chunkserver • 数据存储 • 副本一致性，raft • 客户端 Client • 对元数据增删改查 • 对数据增删改查 • 快照克隆服务器 • 快照 • 克隆快照和克隆的特点 • 快照的定义 快照是云盘数据在某个时刻完整的只读拷贝，是一种便捷高效的数据容灾手段， ChunkId + “_snap_”+ seqNum的形式，以区别于 ChunkFile。CHUNKSERVER端快照实现-SNAPFILE 字段 类型 说明 version uint8_t 文件格式协议 版本号 demaged bool 损坏标记 sn uint64_t 快照版本号 bits uint32_t 位图的位数 bitmap char[] 位图 crc uint32_t 上述字段的crc 无额外接口： 无需Flatten接口。 适用场景： 适用于从云主机或快照创建镜像CHUNKSERVER端克隆实现-CHUNKFILE 字段 类型 说明 version uint8_t 文件格式协议版本号 sn uint64_t chunk文件的版本号 correntSn uint64_t chunk的修正版本号 locationSi ze size_t 可缺省，当前为CloneChunk时表示

© XXX Page 1 of 12 元数据持久化© XXX Page 2 of 12 前言 Raft Log Raft Snapshot 持久化文件 key_value_pairs 其他说明 实现 1、inode、entry 的编码 2、KVStore Q&A 单靠 redis 的 AOF 机制能否保证数据不丢失? redis 的高可用、高可扩方案？ redis + muliraft 参考 前言 根据之前讨论的结果，元数据节点的架构如下图所示，这里涉及到两部分需要持久化/编码的内容： Raft Log：记录 operator log Raft Snapshot：将内存中的数据结构以特定格式 dump 到文件进行持久化© XXX Page 3 of 12 Raft Log +------+------------+-----+----------------+---------+----------+ [value_length] 4 value 长度 [value] $value_length 编码后的 value checksum 8 前面 5 部分的校验和© XXX Page 4 of 12 Raft Snapshot +---------+---------+------+-----------------+-----+-----------+ | CURVEFS | version | size

increases.Data consistency in CurveBS CurveBS uses RAFT as a consistency protocol. The figure above is from the RAFT paper(https://raft.github.io/raft.pdf). CurveBS uses BRaft to implement the consistency Chunkserver processing flow CopysetNode is essentially a wrapper around the RAFT algorithm. The Copyset module encapsulates the RAFT Node of BRaft and implements the user state machine of BRaft. Take a Supports Object storage by S3 apis and CurveBS CurveBS performance considerations 1. CurveBS uses raft as a consistency protocol which requires majority replicas to be successful. Compare with strong

dentry，inode 两层映射关系，所有的元数据都缓存在内存中。元数据是分片的，使用 multi-raft 持久化元数据以及保证多副本数据一致性。基于这种方式开发： a. 性能 由于元数据分片，获取元数据需要跟多个节点进行rpc的交互，因此性能相比单机要弱一些 b. 扩展性/可用性/可靠性 使用 multi-raft, 扩展性、可用性和可靠性与元数据节点一致 对比结论 CurveFS 近期要能 1. 1. 2. 3. 1. 1. 2. 3. metaserver: 元数据服务进程。一个进程管理多个复制组 copyset: 复制组，使用 raft 保证数据一致性。复制组中保存文件系统的部分元数据信息 文件系统元数据和复制组是多对多的关系 一个复制组可以包含多个文件的元数据信息 复制组 wal 记录元数据操作 定期 snapshot 对 1. 2. 3. 1. 4. 5. 1. 2. 3. 4. 5. 由于元数据使用raft, apply的时候是以kv的方式写入到文件，因此可以复用这个逻辑。 客户端感知文件版本号。如果版本号变更，就触发raft的sanpshot，并且只apply小于版本号的部分 这种方式相当于每次都是全量缓存当前元数据，不做增量快照，考虑到转储逻辑，这也是可以接受的