TGT 服务器的优化块设备协议 • NBD • Linux专有块设备协议 • iSCSI • 广泛支持的外部设备协议（块，磁带等）Curve云原生存储支持块设备 • 通过NBD，只支持Linux • 通过SDK API，目前只支持Linux • PFS • 扩大使用范围 • 通过iSCSI支持更多系统，例如Windows, 类UNIX系统等，使用两项基础 技术 • TCP/IP Client端: iscsi initiator，系统自带 • Linux open-iscsi • Windows iSCSI 发起者 • 服务器端 • 必须是CurveBS原生支持的平台，因为需要curve原生接口，目前是LinuxiSCSI target服务器 • LINUX LILO • 一般用于输出内核本地块设备 • TCMU • 作为LILO支持用户态的接口 • 如何评价LILO • ve, brpc, c++, protobuf 等) • TCMU多了一层转接，配置过程复杂，业界踩的坑不够多。 • TCMU的用户态代码会受到框架约束，不够灵活。iSCSI target 服务器 • TGT(STGT) • 比较久的历史，原来叫STGT，后来改成TGT • 纯用户态，不与内核绑定 • 支持复杂的存储系统，例如ceph rbd, sheepdog, glfs • 纯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文件存储 • 基于Openstack构建云计算平台 操作系统 芯片 数据库 云原生 AI训练 大数据 社区生态Curve介绍 01 02 raft和braft 03 raft在Curve中的应用 05 Q&A 04 Curve对raft的优化RAFT协议简介 什么是raft • raft 是一种新型易于理解的分布式一致性复制协议，由斯坦福大学的Diego Ongaro和John Ousterhout提出，《In Search of 速度取决于写的较快的大多数RAFT协议简介 • Leader：负责从客户端接受日志，把日志复制到其 他服务器，当保证安全性的时候告诉其他服务器应用 日志条目到他们的状态机中。 • Candidate: 发起选举。获取大多数选票的候选人将 成为领导者。 • Follower: 响应来自其他服务器的请求，如果接受不 到消息，就变成候选人并发起一次选举。 • 时间被划分成一个个的任期，每个任期开始都是一次

ChunkServer核心模块 新版本ChunkServer性能优化CURVE基本架构 • 元数据节点 MDS • 管理和存储元数据信息 • 感知集群状态，合理调度 • 数据节点 Chunkserver • 数据存储 • 副本一致性，raft • 客户端 Client • 对元数据增删改查 • 对数据增删改查 • 快照克隆服务器CURVE基本架构 01 02 03 04 ChunkServer架构 ChunkServer架构 ChunkServer核心模块 新版本ChunkServer性能优化Curve ChunkServer是数据节点， 对外提供数据读写和节点管理功 能，底层基于ext4文件系统，操 作实际的磁盘。 ChunkServer架构ChunkServer通过RPC网络层与client， MDS，其他ChunkServer通信。RPC 网络层是由brpc框架去完成的。包 括读写socket，rpc协议解析等。 能，内部是一个线程池，主要负责异 步完成克隆chunk的数据补全。关于克 隆相关的内容将会在快照克隆相关介 绍文档中详细介绍。 ChunkServer架构Metric统计模块使用brpc中的bvar计数 器，统计一些IO层面和copyset层面的 一些指标，方便监控和跟踪。 ChunkServer架构并发控制层，负责对chunkserver的IO 请求进行并发控制，对上层的读写请 求安照chunk粒度进行Hash，使得不同

管理元数据信息 收集集群状态信息，自动调度 • 数据节点 Chunkserver 数据存储 副本一致性 • 客户端 Client 对元数据增删改查 对数据增删改查基本架构 • 快照克隆服务器 独立于核心服务 储到支持S3接口的 对象存储，不限制数量 异步快照、增量快照 从快照/镜像克隆 ( lazy/非lazy ) 从快照回滚数据组织形式 • 底层 可用性 / 可靠性 扩展性 1.244 3.2 3.1 0.998 4K随机写 4K随机读 61.12 % 67.8% 测试环境：6台服务器*20块SATA SSD，E5-2660 v4，256G，3副本场景 高性能高性能 • quorum机制：raft • 轻量级快照 • io路径上的优化 • filepool落盘零放大 • 轻量级线性一致性读 • io路径上用户空间零拷贝 10卷4K随机读写IOPS Ceph（L/N） Curve 58.92% 71.21% 10卷4K随机读写平均延迟(ms) 4.34 7 3.7 2.423 4K随机写 4K随机读 38% 34.5% 测试环境：6台服务器*20块SATA SSD，E5-2660 v4，256G，3副本场景高可用 核心组件支持多实例部署，允许部分实例异常 MDS、Snapshotcloneserver 通过 etcd 选主，实现高可用高可用

stripe (增大并发) 8. zerocopy 9. 云原生 核心设计Curve块存储 1. physical pool用于实现对机 器资源物理隔离 2. zone故障隔离的基本单元 3. server表示物理服务器 4. chunkserver物理服务器上 的服务实例 拓扑结构Curve块存储 1. Curve块存储将虚拟块设备 映射到文件 2. 每个文件包含的chunk分散 完善高性能3副本存储引擎，支持混合盘 4. 文件存储支持数据存储到HDFS、rados等引擎 2. 性能 1. 完善RDMA/SPDK方案，发布稳定版本 2. 更高性能硬件选型、适配及性能调优 3. 大文件读写性能优化，RAFT优化，降低写放大 3. 功能 1. 文件存储支持回收站/生命周期管理/配额/用户权限等 2. 支持NFS、CIFS/SMB、HDFS等协议 3. 块存储支持按存储池创建卷Curve 社区介绍

热升级NEBD总体介绍 新版本Client/NEBD性能优化CURVE基本架构 • 元数据节点 MDS • 管理和存储元数据信息 • 感知集群状态，合理调度 • 数据节点 Chunkserver • 数据存储 • 副本一致性，raft • 客户端 Client • 对元数据增删改查 • 对数据增删改查 • 快照克隆服务器CURVE基本架构 01 02 03 04 Client总体介绍 Client总体介绍 热升级NEBD总体介绍 新版本Client/NEBD性能优化 QEMU、Curve-NBD：上层应用  通过链接curve-client使用curve提供的服务  FileManager：提供接口，记录已挂载卷  FileInstance：对应一个已挂载的卷  LeaseExecutor：负责定期与MDS通信，获取卷的元数据信息  元数据信息在打快照时会进行变化 未能返回。所以，在这种情况下，重试请求会将RPC超时时间进行增加。CURVE基本架构 01 02 03 04 Client总体介绍 热升级NEBD总体介绍 新版本Client/NEBD性能优化NEBD 整体介绍 热升级之前，QEMU是直接链接curve-client， 所以client版本需要升级时，需要对QEMU进 程进行重启。NEBD 整体介绍 在QEMU和Curve Client中间加入热升级模块，避

ll底层ext4 • 内核调⽤延迟测试 • 与FUSE Daemon通讯120us左右，FUSE Daemon⼤概10us以内 • 瓶颈在/dev/fuse通讯开销基于FUSE可能的优化点 • 降低内核与libfuse通讯延迟 • 基于⽂件属性的操作内核直接返回？ • 基于⽂件数据的操作先内核读写 cache？实现POSIX兼容API途径及问题 • 基于FUSE的实现 fuse_ll_ops开销10us-基于FUSE的优化框架 • 框架优化的要点 • 共享inode cache • 共享data cache的映射 • GETATTR流程 • ⽂件读取流程 • 相关⼯作 • extFUSE • google android12 passthrough什么是eBPF • ebpf是不同环境下内核配置， 调试，监控⼯具 • map映射 • 验证器 • Hook 与底层⽂件关系 (filename, offset, len) = func (inodeid, offset, len) • 读cache流程 • 写cache流程基于inode cache优化 • bpf程序类型 BPF_PROG_TYPE_EXTFUSE • Hook点及⽅法 • fuse_request_send • FUSE_LOOKUP / FUSE_GETATTR

文件系统的元数据是否全缓存？ 元数据持久化在单独的元数据服务器上？在磁盘上？在volume上？ inode+dentry方式？当前curve块存储的kv方式？ 是否有单独的元数据管理服务器？ 2、其他文件系统的调研总结 fs 中心化元数据 内存namespace元数据 内存空间分配元数据 元数据持久化 元数据扩展 小文件优化 空间管理单位 数据持久化 其他© XXX Page 3 of 有元数据服务器 全内存 fsnode → hashtable(inode id) fsedge → hashtable (parent inode + name) 全内存 chunk → hashtable(chunk id) log + dump record 差 否 chunk 链式多副本 overwirte有数据不一致风险 chubaofs（cfs） 有元数据服务器 inode 更适合大文件顺序写 fastcfs 有元数据服务器 inode和dentry放一个结构体。 inode → hashtable（key是ino，全局） dentry → skip list （key是name，每个目录下一个） 计算出来的 binlog，随时间会越来越大 差 DG Master/Slave glusterfs 无中心化服务器 dht算法 hash 扩展时大量迁移

样： →pool ：存储池（curve的physical pool和logic pool这里合并，只保留一个pool） →zone：可用域 →server：代表着一台服务器 →metaserver：代表着一块盘© XXX Page 9 of 19 每个copyset的由处于不同zone的metaserver组成复制组。 5、curvefs mds和metaserver的心跳 CopySetScheduler: copyset均衡调度器。根据集群中copyset的分布情况生成copyset迁移任务； LeaderScheduler: leader均衡调度器。根据集群中leader的分布情况生成leader变更任务； ReplicaScheduler: 副本数量调度器。根据当前copyset的副本数生成副本增删任务； RecoverScheduler: 恢复调度器。根据当前copyset副本的存活状态生成迁移任务。 状态生成迁移任务。 结论：心跳参考curve。目前这些调度器在curvefs第一阶段不用全部实现。所有和均衡相关的，暂时不做。只做和故障处理相关的副本补全恢复的调度。 6、详细设计 6.1 创建fs curvefs管理工具发起创建fs命令，mds收到createfs命令之后，在mds插入的一条fs记录，状态为NEW。然后为fs创建copyset，默认为3个。mds调用topology的接口

分配器，用于分配并存储文件数据。 CurveFS方案设计（总体设计，只实现了部分） 本地文件系统空间分配相关特性 局部性 尽量分配连续的磁盘空间，存储文件的数据。这一特性主要是针对HDD进行的优化，降低磁盘寻道时间。 延迟分配/Allocate-on-flush 在sync/flush之前，尽可能多的积累更多的文件数据块才进行空间分配，一方面可以提高局部性，另一方面可以降低磁盘碎片。 Inline 文件系统重新加载时，再将所有的空间，按照上述的策略，进行分组管理。 接口设计 RPC接口 当前设计是把空间分配器作为内置服务放在元数据节点，所以请求的发起方是fuse client，元数据服务器接收到请求后，根据fsId查找到对应的文件系统的空间分配器后，将空间分配/回收的任务交给这个分配器进行处理，处理完成后，返回RPC。 空间分配器相关的RPC接口，及request/response定义如下。与