© XXX Page 1 of 9 Curve支持S3 数据缓存方案© XXX Page 2 of 9 版本 时间 修改者 修改内容 1.0 2021/8/18 胡遥 初稿 背景 整体设计 元数据采用2层索引 对象名设计 读写缓存分离 缓存层级 对外接口 后台刷数据线程 本地磁盘缓存 关键数据结构 详细设计 Write流程 Read流程 ReleaseCache流程

1 用UCX实现BRPC对RDMA的支持 徐逸锋2 BRPC简介 ●BRPC是Curve的基础通讯框架 ●支持远程过程调用 –C++ –TCP传输 –bthread协程(m:n调度，减少基于内核的下文切换 ，减少cache miss) ●多协议支持 –baidu_std,http,grpc… ●protobuf3 BRPC简介 ●Client/Server架构 ●使用Protobuf定义协议文件 例子：Request输入处理19 Channel创建Socket20 Channel远程调用的发起21 UCX ●NVIDIA Mellanox 开源项目 ●支持RDMA，TCP，Shared memory等 ●能透明支持多个链路传输，例如多网卡bond ●编译成.so或lib的方式，可以集成到应用程序里 ●有完善的配置功能，ucx_info可以dump配置信息 ●有性能测试工具 ●特点是比较原始，开销小，但是没有很强的功能 ●是网络接口层，主要功能是网卡发现和远程内存传输支持，提供component查询和 memory domain的打开 ●一个component包含若干 memory domain resource,一个memory domain又可以包含若干个 transport ●当前支持的memory domain：ibverbs, tcp, shared memory

open接口原型 open flags flags定义 flags的含义 libfuse open open flags 在curvefs上的测试 open flags 实现方式 整体flags支持方案 具体flag的实现方案 O_TRUNC I/O模式类 O_DIRECT O_SYNC, O_DSYNC O_NONBLOCK(O_NDELAY ), FASYNC, O_TMPFILE 结论 ，此时等同于open。 open flags flags定义 flags通过宏定义实现，定义见 ，主要包括如下flag fcntl.h # 红色是不支持且会执行结果错误；橙色是暂不确定但不影响写入结果；紫色为暂时无法测试；黑色是已经支持 #define O_RDONLY 00000000 #define O_WRONLY 00000001 #define O_RDWR 00000002 #define 当pathname对应的文件不存在时则创建它，文件uid为进程uid，gid为进程gid或父目录gid（取决于SGID是否置位）；当flags中出现O_CREAT 或 O_TMPFILE时，mode参数必须提供，否则会使用栈中随机字节填充；通常在没有ACL的情况下，有效的mode是经过与进程mask作用后的结果（mode & ~mask)。 # symbolic constants S_IRWXU 00700 S_IRUSR

/A/C到/B/E hardlink：生成一个hardlink /B/E，指向文件/A/C 6、curve文件系统的多文件系统的设计 1、设计一个分布式文件系统需要考虑的点： 文件系统的元数据是否全缓存？ 元数据持久化在单独的元数据服务器上？在磁盘上？在volume上？ inode+dentry方式？当前curve块存储的kv方式？ 是否有单独的元数据管理服务器？ 2、其他文件系统的调研总结 小文件优化 空间管理单位 数据持久化 其他© XXX Page 3 of 24 moosefs（mfs） 有元数据服务器 全内存 fsnode → hashtable(inode id) fsedge → hashtable (parent inode + name) 全内存 chunk → hashtable(chunk id) log + dump record 差 否 chunk Page 7 of 24 场景一：系统加载的时候，元数据从持久化介质中加载。 元数据进行恢复的时候，有两种情况。 一种系统必须等到元数据全部加载到内存才能提供服务，这种情况下，元数据需要在内存全缓存。这种方式，对性能友好，但是需要消耗比较多的内存，元数据服务的扩展性受限于内存，而且在元数据服务启动的 时候，需要等待一段时间加载内存。 一种是元数据需要全部加载到内存，这种情况下，元数据只需要

易用性：跨平台，超融合，弹性 小型主机 容量有限分布式存储的分类 按照各种应用场景所需的存储接口分类 对象 存储 文件 存储 块存储 接口为简单的 Get、PUT、DEL 和其他扩展 通常意义是支持 POSIX 接口 传统意义的文件系统： Ext4 对指定地址空间进行随机读写 传统意义的块存储：磁盘分布式存储的要素 如何构建分布式文件系统？ 以分布式块存储为例。 •提供大容量的块设备 03 04 Ceph 架构简介 | 块存储场景 | 使用中的问题 Curve 架构简介 | 数据对比 | 应用情况 FAQ 答疑架构简介 — 总体架构 开源分布式存储界的扛把子 支持块存储、文件存储、对象存储架构简介 — 概念介绍 object：存储单元 PG：Placement Groups 归置组 归置组中的成员为副本 OSD：Object 所有副本写完成返回客户端 • 延迟取决于所有副本中最慢的那一个块存储场景 为云主机提供云盘，云盘提供随机读写、快照（数据备份，灾备使用）、镜像（模板，自定义）功能。块存储场景 为物理机提供块设备 Linux IO栈 应用程序 -> 文件系统 -> 块设备层 -> 不同协议/驱动使用中的问题 • io抖动（一致性协议）： 异常场景（比如阵列卡一致性巡检，坏盘，慢盘，网络异常），服务升级 • 性能差（一致性协

不影响转储 • 增量转储，第一次全量转储s3之后，后续只需转储增量部分 • 高可用，快照任务中断自动拉起继续转储快照和克隆的特点 • 克隆的定义 • 克隆是指从卷复制出卷的功能，提供快速的复制卷的能力。 • 这里的克隆还包括从快照回滚的功能 • 克隆的特点 • 支持Lazy和非Lazy两种模式克隆 • 支持从快照克隆和从镜像（卷）克隆 • 支持从快照回滚 • 高可用，克隆任务中断自动拉起继续克隆快照克隆服务器架构 chunkMap 快照chunk映射表 MetaObject： • 保存完整的chunk数据，大小为一个 Chunk的大小，即16MB DataObject： • 打快照时读取当前目标卷的所有快照的全 部metaObject • 根据本快照的chunk映射表，判断当前的 快照chunk是否需要转储 增量转储原理：快照在CHUNKSERVER上的数据组织  快照chunk和普通chunk，都是

卷和文件系统 元数据架构 文件系统快照 方案一：文件/目录级别快照 方案二：文件系统快照 关键点 元数据设计 数据结构 索引设计 文件空间管理 开发计划及安排 背景 为更好的支持云原生的场景，Curve需要支持高性能通用文件系统，其中高性能主要是适配云原生数据库的场景。当前Curve是实现了块存储，向上提供块设备服务，CurveFS会基于此实现。第一阶段的目标是实现 满足数据库场景的文件接口。 的管理形式？留有租户这个概念），直接基于 namespace 开发： a. 功能 软/硬链接：目前是都不支持的。软链接可以通过标识文件类型解决；由于 prefix + parentid + filename 作为 key , filename 直接和 fileInfo 关联，硬链接无法支持 b. 性能 list：list在通用文件系统中是很常见的操作，目前 curve 的元数据缓存使用的 一些 b. 扩展性/可用性/可靠性 使用 multi-raft, 扩展性、可用性和可靠性与元数据节点一致 对比结论 CurveFS 近期要能支持mysql所要接口，长期需要支持通用文件接口。 kv 虽然改造简单，短期内对基本功能的支持没有问题，但这个架构不利于 Curve 长期的规划和演进，因此选择通用的 dentry，inode 两层映射的元数据结构。对于 fs© XXX Page

实例（leveldb 中的 wal 和 SST 文件都可以写到指定的目录) redis 改造 vs 自己实现? 结论：从目前元数据持久化的需要来看，更倾向于自己实现，理由如下： redis 目前不支持单独持久化 redis 中的某个 DB (一个 redis 实例可包含多个 DB) 或数据结构，这对于在要使用 multiraft 的场景下，每个 raft 实例需要独立的快照并不合适 如果改造 要大一些，改造主要是为了让 redis 提供单独 dump/load 一个 DB 的功能： 如果改造，dump/load 的逻辑都得动，而且会牵扯到一些其他逻辑（如主从复制，因为 redis 主从全量复制发送的就是一整个 RDB 文件，即使我们不需要这个功能，这部分代码也是有耦合的）© XXX Page 11 of 12 1. 2. 3. 如果自己实现，只是一个简单的 sava/load

12之前 initial RTO是⼀个常数1s • 应⽤类型BPF_PROG_TYPE_SOCK_OPS • HOOK BPF_SOCK_OPS_TIMEOUT_INIT • 内核中调⽤栈 • tcp_timeout_init • tcp_call_bpf(BPF_SOCK_OPS_TIMEOUT_INI T) • bpf_cgrougp_run_sock_ops •

PolarDB开发大赛: 230+参赛选手 21K+ 社区用户 • 全面开源 • 兼容PG&MySQL • 透明分布式 • HTAP • 企业特性(闪回、TDE、冷热分离...) 50+全链路伙伴: 韵达、莲子数据、网易数帆、 龙蜥、武汉大学 ... 等 需求 手段 需求 手段 需求 手段 需求 手段 需求 手段欢迎加入PolarDB开源生态