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

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作为云原生数据库的高性能存储 底座，完美支持云原生数据库的存算分离架 底座，完美支持云原生数据库的存算分离架 构 • Curve作为云存储中间件使用S3兼容的对象 存储作为数据存储引擎，为公有云用户提供 高性价比的共享文件存储 • 支持在物理机上挂载使用块设备或FUSE文件 系统开源社区 社区运营 生态共建 开源共建 源码兜底 技术领先 目标 方法 影响力 降本 获客 用户 开发者 操作系统 芯片 数据库 云原生 AI训练 大数据 社区生态Curve介绍

— Curve Maintainer XAgenda 第二 第三 第四 第一 Curve的由来 Curve的设计目标 Curve块存储 和 Curve文件存储 Curve社区Curve的由来 1. 代码复杂/代码量大 2. 运维难度高 3. 无法满足高的性能需求Curve的设计目标 1. Curve云原生软件定义存储 2. Curve块存储 3. Curve文件存储 器资源物理隔离 2. zone故障隔离的基本单元 3. server表示物理服务器 4. chunkserver物理服务器上 的服务实例 拓扑结构Curve块存储 1. Curve块存储将虚拟块设备 映射到文件 2. 每个文件包含的chunk分散 在集群的存储节点 3. chunkserver按照故障域分组 4. copyset中的节点属于不同的 故障域 数据组织Curve块存储 chunkserver负责数据的存储 2. RAFT协议保持数据的一致 性 3. chunkfile pool降低元数据开 销 Chunkserver服务Curve块存储 性能设计Curve块存储 在线升级设计 1. 客户端分成NebdClient与 NebdServer两部分 2. NebdClient只做简单的转发 3. NebdServer实现大部分的客 户端逻辑Curve块存储

• Curve的应⽤场景及挑战 • Curve客户端⾯临问题及分析 • 什么是ebpf • 基于epbf的Curve Cache设计 • Curve社区介绍Curve是什么？ • Curve云原⽣软件定义存储 • Curve分布式块存储 • Curve分布式⽂件存储 • ⾼性能、易运维、云原⽣Curve⽂件系统框架和主要应⽤场景 • AI机器学习场景 • ⼤数据计算场景 ⼤数据计算场景 • 中间件数据存储场景 • ⽀持POSIX兼容的⽂件API • ⽀持低延迟的⽂件数据访问Curve⽂件系统⾯临的问题 • ⽤户态实现 • 稳定性/可靠性⾼ • 容易更新及维护 • 基于FUSE提供POSIX兼容⽂件接⼝ • 问题 • 相对kernel⽂件系统的实现(ext4, xfs)性能 差异⼤，延迟⾼FUSE⽂件IO读写流程 • 场景1 pytorch word_language_model • LOOKUP inode 返回 fstat + timeout设置 • OPEN 打开 inode返回ok • GETATTR 返回fstat • READ inode 读取的内容不等从16KB到128KB • 关闭⽂件时会发送FLUSH请求和RELEASE请求 • 场景2 解压压缩包场景 • LOOKUP inode 没有该inode • CREATE创建⽂件句柄并返回fstat

协同育人、教学优化成果 获客 影响力 职业发展 技能成长 获客 降本 影响力 新商机、 降本 合作沙龙、比赛 合作项目、解决方案 参与社区分享 • 编程之夏 • 黑客松 开源课程: (学习、实验、评 测、认证、实践、 代码协作) • 训练营 • 电子书 • 评测局 • 开源认证考试 • 开源学堂 • 内核课程 PolarDB开源社区 (2W+用户) 技术委员会 开源社区治理 • 联合解决方案|产品 • OxM发型版 • 数据库管理产品 • 数据迁移、联邦产品 生态伙伴合作 高校合作 学习、分享、比赛、贡献 服务客户 开源共建 社区运营 生态建设 获得生态 商业服务 使用开源 PolarDB 开源学习 开源共建 人才招聘 产品适配 OxM 源码兜底 技术领先 PolarDB开源生态 共建模式 国产化替代 应用软件 适配迁移 接入云端销售 数据价值放大 • 基础设施 • 安全 • 管理维护 • 数据集成 • 开发协同 • ISV • 培训育人 • 商业服务 • ... 2022S1: 3500W曝光 150W学习人次 2万+实践体验 2K+持证人才 PolarDB开发大赛: 230+参赛选手 21K+ 社区用户 • 全面开源 • 兼容PG&MySQL • 透明分布式 • HTAP • 企业特性(闪回、TDE、冷热分离

2、chubaofs的元数据管理 2.1、meta partition的创建 2.2、meta partition的管理 2.3、meta partition和inode以及dentry的对应关系？ 3、curvefs的copyset和fs的对应关系 3.1 如何获取inodeid 3.2 copyset fs共用吗？ 3.3 copyset个数是否可以动态调整？ 4、curvefs的topo信息 5、curvefs mds和metaserver的心跳 6、详细设计 6.1 创建fs 6.2、挂载fs 6.3、创建文件/目录 6.4、open流程 6.5、读写流程 6.6、topology 7、工作评估 7.1 client端 7.2 mds端 7.3 metaserver端 metaserver 子模块拆分 8、inode和dentry的内存估算 8.1 一台机器上能存放多少个inode和dentry 一台机器上建议的copyset数量 8.3 每个copyset建议管理存储容量的大小 1、背景 curvefs使用raft作为元数据一致性的保证。为了提高元数据的可扩展性和并发处理能力，采用元数据分片的方式管理inode和dentry的元数据。inode的分片依据是fsid + inodeid，dentry的分片依据是fsid + parentinodeid。借鉴curve块设备的设计思路，（补充copyset的设计文档在这

XXX Page 2 of 24 1. 2. 3. 4. Inode 1、设计一个分布式文件系统需要考虑的点： 2、其他文件系统的调研总结 3、各内存结构体 4、curve文件系统的元数据内存组织 4.1 inode定义： 4.2 dentry的定义： 4.3 内存组织 5 元数据分片 5.1 分片方式一：inode和dentry都按照parentid分片 5.1.1 /B/E，指向文件/A/C 6、curve文件系统的多文件系统的设计 1、设计一个分布式文件系统需要考虑的点： 文件系统的元数据是否全缓存？ 元数据持久化在单独的元数据服务器上？在磁盘上？在volume上？ inode+dentry方式？当前curve块存储的kv方式？ 是否有单独的元数据管理服务器？ 2、其他文件系统的调研总结 fs 中心化元数据 内存namespace元数据 有元数据服务器 inode → b tree(key ino) dentry → b tree (key parentIno + name) extent → B+ tree 这个在inode的ExtentsTree字段 meta partition(raft group) Btree、B+ tree 好 有 tiny extent，多个文件共用 normal extent，属于一个文件

关键点 元数据设计 数据结构 索引设计 文件空间管理 开发计划及安排 背景 为更好的支持云原生的场景，Curve需要支持高性能通用文件系统，其中高性能主要是适配云原生数据库的场景。当前Curve是实现了块存储，向上提供块设备服务，CurveFS会基于此实现。第一阶段的目标是实现 满足数据库场景的文件接口。 调研 开源fs 当前对已有的开源分布式文件系统进行了调研，主要包括系统架构， 并对以上文件系统在相同环境进行了元数据节点性能测试： 。测试结果c开发的moosefs和fastcfs元数据性能远优于go开发的chubaofs和c开发的cephfs，理论上分析这个结果是合理的，分布式的元数据设 调研测试 计会涉及到多次rpc的交互。这里需要确认的一点是：我们需要怎样的元数据节点的性能？ 可行性分析 方案对比 根据上述调研和测试结果，我们考虑了三种curvefs的元数据设计方案： CurveFS kv方案设计 kv方案设计 curve实现块设备时，元数据不是扁平化的设计，而是采用来有目录层级的 namespace 方式，namespace 已经实现了 fs 元数据管理的雏形，具备了基本的元数据管理功能。（当时为什么要设计为 namespace 的管理形式？留有租户这个概念），直接基于 namespace 开发： a. 功能 软/硬链接：目前是都不支持的。软链接可以通过标识文件类型解决；由于 prefix

技术选型 3. etcd clientv3的concurrency介绍 3.1 etcd clientV3的concurrency模块构成 3.2 Campaign的流程 3.2.1 代码流程说明 3.2.2 举例说明Campagin流程 3.3 Observe的流程 4. MDS使用election模块的功能进行选主 4.1 Curve中MDS的选举过程 4.2 图示说明选举流程 4 异常情况2：Etcd集群的leader发生重新选举，MDS1未受影响，可以正常处理 4.2.4 异常情况3：Etcd的leader发生重新选举，MDS1受到影响退出，不一定可以正常处理。 4.2.4.1 LeaseTIme < ElectionTime的情况 4.2.4.2 GetTimeout < ElectionTime 4.2.4.3 MDS1、MDS2、MDS3的租约全部过期 4.2.4 异常情况4：Etcd集群的follower节点异常 4.2.7 各情况汇总 1. 需求 mds是元数据节点，负责空间分配，集群状态监控，集群节点间的资源均衡等，mds故障可能会导致client端无法写入。 因此，mds需要做高可用。满足多个mds, 但同时只有一个mds节点提供服务，称该提供服务的mds节点为主，等待节点为备；主节点的服务挂掉之后，备节点能启动服务，尽量减小服务中断的时间。 需要解决的问题就是：如何确定主备节点。

是否需要做session机制（在metaserver打开），来维护inode的打开情况？ 方案设计 Trash机制： Session机制： 遗留问题 工作量评估 背景 目前curvefs client版本对删除unlink和rmdir的设计只有简单的删除inode和dentry结构，遗留了nlink和lookup count相关的内容还未实现，是不完备的。本文首先调研moosefs，chubaofs等分布式系统，参考并设计解决上述遗留问题。 ret; } 存在两个问题: 一是删除时nlink字段未考虑： 文件的nlink用于实现hard link。 hard link使用nlink字段表示文件的link的引用计数，第一次创建文件是nlink字段为1。每创建一个新的指向该文件的hard link时,nlink字段+1， 每删除一个hard link或指向的原文件时，nlink字段-1。© XXX Page 4 of 15 当nl ，才真正的执行删除inode。 目录的nlink字段与文件的nlink字段不同， ， 并且在目录下， ， 删除目录nlink相应的减1。 目录的nlink字段初始值为2 每创建一个新目录，nlink字段也会+1 目录不支持硬链接。 二是删除时lookup count未考虑： lookup count 指的是文件的访问计数。当文件/目录被打开时， ，该文件/目录仍然可以被打开的进程访问