TGT 服务器的优化块设备协议 • NBD • Linux专有块设备协议 • iSCSI • 广泛支持的外部设备协议（块，磁带等）Curve云原生存储支持块设备 • 通过NBD，只支持Linux • 通过SDK API，目前只支持Linux • PFS • 扩大使用范围 • 通过iSCSI支持更多系统，例如Windows, 类UNIX系统等，使用两项基础 技术 • TCP/IP target服务器 • LINUX LILO • 一般用于输出内核本地块设备 • TCMU • 作为LILO支持用户态的接口 • 如何评价LILO • 输出内核块设备I/O效率高 • 不利于把复杂的存储协议代码搬进内核，例如(curve, brpc, c++, protobuf 等) • TCMU多了一层转接，配置过程复杂，业界踩的坑不够多。 • TCMU的用户态代码会受到框架约束，不够灵活。iSCSI 编写IO驱动比较容易，容易扩展支持新的存储系统 • 代码独立，容易编译、调试、修改，适应性强让TGT支持curve • 编写curve驱动，底层异步提交I/O，pipeline • 利用NEBD PART 1接口，需要与nebdserver运行在同一台机器 • 支持共享打开，两台TGT服务器可以同时打开一个curve卷 • 让Initiator可以使用multipath • 支持卷resize • 添加新的命令

稳定性挑战 • 算力平台kubernetes的迅速发展 • AI/大数据业务的快速增长 • 存储使用Ceph文件存储/HDFS • 成本/性能挑战 Curve块存储和文件存储均采用raft协议整体架构 • 对接OpenStack平台为云主机提供高性能块 存储服务 • 对接Kubernetes为其提供RWO、RWX等类 型的持久化存储卷 • 对接PolarFS作为云原生数据库的高性能存储 社区生态Curve介绍 01 02 raft和braft 03 raft在Curve中的应用 05 Q&A 04 Curve对raft的优化RAFT协议简介 什么是raft • raft 是一种新型易于理解的分布式一致性复制协议，由斯坦福大学的Diego Ongaro和John Ousterhout提出，《In Search of an Understandable Consensus Version)》 • raft 是一种Leader-Based的Multi-Paxos变种，提供了更完整更清晰的协议描述，更容易理解和实现。 • raft可以解决分布式理论中的CP，即一致性和分区容忍性 • 大多数副本成功即可返回成功 • 速度取决于写的较快的大多数RAFT协议简介 • Leader：负责从客户端接受日志，把日志复制到其 他服务器，当保证安全性的时候告诉其他服务器应用 日志条目到他们的状态机中。

pgbench 延迟降低21% TPS提升26% 研究现状Curve块存储 1. 分布式块存储服务 2. KVM块存储服务 3. iSCSI协议 4. 容器云块存储(CSI) 应用场景Curve块存储 1. 高可用性/高可靠性 (易运维) 2. RAFT一致性协议 3. CopySet分配算法 4. 拓扑结构 5. 高性能 6. chunkfilepool (降低写放大) 7. data IO流程Curve块存储 1. chunkserver负责数据的存储 2. RAFT协议保持数据的一致 性 3. chunkfile pool降低元数据开 销 Chunkserver服务Curve块存储 性能设计Curve块存储 在线升级设计 1. 客户端分成NebdClient与 NebdServer两部分 2. NebdClient只做简单的转发 3. NebdServer实现大部分的客 功能 1. 文件存储支持回收站/生命周期管理/配额/用户权限等 2. 支持NFS、CIFS/SMB、HDFS等协议 3. 块存储支持按存储池创建卷Curve 社区介绍 1. Curve的成长离不开社区贡献者的支持和参与。非常欢迎广大 社区用户为Curve贡献代码、文档，提交issue和改进网站。我 们愿意为您提供必要的支持 2. 社区成员组成： 网易杭研、网易云音乐、腾讯、zstack、西安邮电大学生等等

–C++ –TCP传输 –bthread协程(m:n调度，减少基于内核的下文切换 ，减少cache miss) ●多协议支持 –baidu_std,http,grpc… ●protobuf3 BRPC简介 ●Client/Server架构 ●使用Protobuf定义协议文件 –例如: echo.proto:4 BRPC简介 client server EchoRequest EchoResponse5 ●Tag match ●client/server模式的Listener, Ep(endpoint)26 UCP ●构建于uct之上，实现更加高级的功能,容易使用，但有一定开销。 ●UCT和UCP两者都有context概念，但是UCT只对一块网卡，而UCP把若干个UCT组合起 来，自动选择最快路径传输。 ●高级特性 –大消息报文的自动分片传输 –Active message, atomic poll –--brpc_ucp_worker_poll_time为wait模式时，一次突发的poll的时长 –--brpc_ucp_deliver_out_of_order为true，接收端乱序提交 –--brpc_ucp_close_flush，release connection时发送未未完成的报文，不是必须的，因为 brpc通常是需要接收应答的,服务器端一般不主动关闭连接，客户端主动关闭，自己负

造成巨大的锁开销，这个是不能接受的。 curve块设备的元数据管理，在分配数据的时候，offset一开始就是知道的，这是和curvefs分配很大的一个不同点。 假设已经确定了一个分片规则，那么根据这个分片规则，一定可以找到两个函数 inodeid到copyset的映射：copysetid = getPartition(inodeid) copyset管理的inode的范围：inoderange = getInodeRange(copyset)© 如何获取inodeid 在create inode的时候，并不知道inode id，inode id是在创建完成之后返回的，这就没有办法利用分片规则去确定到底应该由哪个copyset去服务这个inode。 。 有两种思路 思路一：client在创建inode的时候，先去mds去获取一个inodeid，然后根据这个inode id找到服务这个inode的分片。出于性能上的考虑的，client可以一次从mds获取 独占copyset。原因是，为了避免fs独占copyset 带来的copyset数量过多影响性能的问题。 3.3 copyset个数是否可以动态调整？ 根据copyset个数是否可以动态调整，有两种实现。 一种是curve块存储方案，在集群初始化的时候，把所有的copyset创建好。采用这种方式， 可以采用hash的方式去确定inode的分片。比如说， ， copysetid = (fsid

作实际的磁盘。 ChunkServer架构ChunkServer通过RPC网络层与client， MDS，其他ChunkServer通信。RPC 网络层是由brpc框架去完成的。包 括读写socket，rpc协议解析等。 ChunkServer架构RPC Service层是对外提供的一些RPC服 务的接口。包含的RPC服务有： • ChunkService。IO相关操作 • CliService。成员变更相关操作 实现了braft的状态机，完成与raft的交 互。详细交互流程后面展开。 CopysetNodeManager负责管理 CopysetNode的创建、初始化、删除等 ChunkServer架构心跳模块有两方面的职责： 1、向MDS节点上报心跳，心跳中包括 ChunkServer本身的一些统计信息 2、解析MDS的心跳response中的raft 成员变更信息，向CopysetNode发起变 更 ChunkServer架构ChunkOpRequest模块封装了对 ChunkService到达的I/O请求的实际处 理过程。请求到来时，封装一个 OpRequest，将上下文保存在里面，然 后发起Propose提交给raft，等raft apply后再执行后面的操作。 ChunkServer架构CloneManager主要负责克隆相关的功 能，内部是一个线程池，主要负责异 步完成克隆chunk的数据补全。关于克

是网易针对块存储、对象存储、云原生数据库、EC等 多种场景自研的分布式存储系统：  高性能、低延迟  当前实现了高性能块存储，对接OpenStack和 K8s  网易内部线上无故障稳定运行近两年  已完整开源 • github主页： https://opencurve.github.io/ • github代码仓库： https://github.com/opencurve/curve 软件质量的定义是：软件与明确地和隐含地定义的需求相一致的程度。 为了确保最终交付的软件满足需求，必须将质量控制贯穿于设计、开发到测试的整个流程中。 设计  设计流程  文档规范 开发  编码规范与提交流程  版本管理 测试  测试方法论  CI与异常测试 6/33设计流程 Curve团队采用敏捷开发模式，负责人在制定迭代计划时，确认哪些任务需要设计 文档：  小需求（改动 Guides（https://google.github.io/styleguide/） 9/33新代码提交 Dailybuild测试 提交issue 开发设计 提交PR review +1 CI测试（编译、静态检 查、单元测试、集成测 试、覆盖率80%卡点） 合入master 分支 代码提交流程 异常自动化 测试 混沌测试 （每周一次） CI测试（编译、静态检 查、单元测试、集成测

背景 CurveFS初步设计见 ， 目前需细化Client端设计 CurveFS方案设计（总体设计，只实现了部分） 概述 CurveFS client 向上提供两层接口，分别是© XXX Page 3 of 11 对接fuse，提供通用文件系统接口。对于fuse接口，先前进行了一些调研，见FUSE调研 提供lib库，提供对接分布式数据库接口，这一部分，可参考polarfs的接口，如下图所示。 如果dentry缓存中不存在对应的inode，则从mds根据parent inode id获取parent inode 所在copyset，metaserver ip等信息 ，然后从metaserver获取denty（这里有两种方式，一种是只获取当前需要的 denty，一种是list整个目录的denty，这个需要考虑用哪个接口） 根据找到的denty结构，获取inodeid，设置 fuse_entry_param，返回给fuse 根据inode id，从mds获取inode所在copyset，metaserver ip等信息，然后从metaserver获取inode结构，缓存之； 判断上述各种oflag，执行相应的操作。（ ） 对于目前阶段来说，open可以什么都不做 create & mknod void (*create) (fuse_req_t req, fuse_ino_t parent, const char *name

步两者的copyset信息 • 支持配置变更功能，在心跳回复报文中下发mds发起的配置变更命令，并在后续心跳中获取配置 变更进度。HEARTBEAT MDS端：mds 端的心跳主要由三个部分组成： • TopoUpdater: 根据 chunkserver 上报的 copyset 信息更新拓扑 中的信息。 • ConfGenerator: 将当前上报的 copyset 信息提交给调度模块， kserver状态。 Chunkserver端：chunkserver 端的心跳由两个部分组成： • ChunkServerInfo/CopySetInfo: 获取当前 chunkserver 上的 copyset 信息上报给 MDS。 • Order ConfigChange: 将 MDS 下发的任务提交给对应的 对应 模块执行。HEARTBEAT Chunk server的状态更新： 心跳正常 心跳正常 超过miss时间 未超过offline时间 UNSTABLE ONLINE OFFLINESCHEDULE Schedule（系统调度）是为了实现系统的自动容错和负载均衡，这两个功能是分布式 存储系统的核心问题，也是 curve 是否能上生产环境的决定因素之一。 • 自动容错保证常见异常（如坏盘、机器宕机）导致的数据丢失不依赖人工处理，可 以自动修复。 • 负载均衡

高可用，快照任务中断自动拉起继续转储快照和克隆的特点 • 克隆的定义 • 克隆是指从卷复制出卷的功能，提供快速的复制卷的能力。 • 这里的克隆还包括从快照回滚的功能 • 克隆的特点 • 支持Lazy和非Lazy两种模式克隆 • 支持从快照克隆和从镜像（卷）克隆 • 支持从快照回滚 • 高可用，克隆任务中断自动拉起继续克隆快照克隆服务器架构 • 基于brpc提供restful API的对外http接口 ChunkId + “_snap_”+ seqNum的形式，以区别于 ChunkFile。CHUNKSERVER端快照实现-SNAPFILE 字段 类型 说明 version uint8_t 文件格式协议 版本号 demaged bool 损坏标记 sn uint64_t 快照版本号 bits uint32_t 位图的位数 bitmap char[] 位图 crc uint32_t 上述字段的crc 部快照 a) 打快照后未写过，未触发cow， 无snap file产生，直接读取chunk file b) 打快照后写过，触发了cow， 有snap file， 合并读取 c) 卷从未写过， 两者都没有，返回NOTEXIST 转储内部快照，即读内部快照的三种情况：克隆总体流程 • 1. 用户发起克隆，生成克隆任务，并持 久化任务元数据到etcd，开始执行克隆 任务。 • 2. 调用mds接口创建clone卷信息，该