© XXX Page 1 of 14 CurveFS方案设计（总体设计，只实现了部分）© XXX Page 2 of 14 时间 修订人 修订内容 2021-03-23 李小翠 初稿(背景，调研，架构设计) 2021-03-30 李小翠 增加快照部分 2021-04-13 李小翠、陈威 补充元数据数据结构 2021-04-19 李小翠、吴汉卿、许超杰等 补充文件空间分配，讨论与确认 背景 背景 调研 开源fs 性能对比 可行性分析 方案对比 对比结论 架构设计 卷和文件系统 元数据架构 文件系统快照 方案一：文件/目录级别快照 方案二：文件系统快照 关键点 元数据设计 数据结构 索引设计 文件空间管理 开发计划及安排 背景 为更好的支持云原生的场景，Curve需要支持高性能通用文件系统，其中高性能主要是适配云原生数据库的场景。当前Curve是实现了块存储，向上 结果是合理的，分布式的元数据设 调研测试 计会涉及到多次rpc的交互。这里需要确认的一点是：我们需要怎样的元数据节点的性能？ 可行性分析 方案对比 根据上述调研和测试结果，我们考虑了三种curvefs的元数据设计方案： CurveFS kv方案设计 curve实现块设备时，元数据不是扁平化的设计，而是采用来有目录层级的 namespace 方式，namespace 已经实现了 fs 元数

© XXX Page 1 of 11 Curve文件系统空间分配方案（基于块的方案，已实现）© XXX Page 2 of 11 背景 本地文件系统空间分配相关特性 局部性 延迟分配/Allocate-on-flush Inline file/data 空间分配 整体设计 空间分配流程 特殊情况 空间回收 小文件处理 并发问题 文件系统扩容 接口设计 RPC接口 空间分配器接口 背景 根据 ，文件系统基于当前的块进行实现，所以需要设计基于块的空间分配器，用于分配并存储文件数据。 CurveFS方案设计（总体设计，只实现了部分） 本地文件系统空间分配相关特性 局部性 尽量分配连续的磁盘空间，存储文件的数据。这一特性主要是针对HDD进行的优化，降低磁盘寻道时间。 延迟分配/Allocate-on-flush 在sync/flush之前，尽可能多的积累更多的文件数

© XXX Page 1 of 9 Curve支持S3 数据缓存方案© XXX Page 2 of 9 版本 时间 修改者 修改内容 1.0 2021/8/18 胡遥 初稿 背景 整体设计 元数据采用2层索引 对象名设计 读写缓存分离 缓存层级 对外接口 后台刷数据线程 本地磁盘缓存 关键数据结构 详细设计 Write流程 Read流程 ReleaseCache流程 因此需要通过Cache模块解决以上2个问题。 整体设计 整个dataCache的设计思路，在写场景下能将数据尽可能的合并后flush到s3上，在读场景上，能够预读1个block大小，减少顺序读对于底层s3的访问频次。从这个思路上该缓存方案主要针对的场景是顺序写和顺序 读，而对于随机写和随机读来说也会有一定性能提升，但效果可能不会太好。 元数据采用2层索引 由于chunk大小是固定的（默认64M），所以Inode中采用map方案。 写缓存一旦flush即释放，读缓存采用可设置的策略进行淘汰（默认LRU），对于小io进行block级别的预读。 即读写缓存相互没影响不相关， 缓存层级 缓存层级分为fs->file->chunk->datacache

© XXX Page 1 of 11 curvefs对接s3方案设计（过程文档）© XXX Page 2 of 11 时间 修订人 修订内容 2021-05-20 胡遥 初稿 2021-07-20 胡遥 细化write和read流程 整体架构 整体思路 接口和关键数据结构 mds.proto client端数据结构 metaserver.proto space相关数据结构和proto

Curvefs-S3 本地写缓存盘方案© XXX Page 2 of 9 背景 方案设计 主要数据结构定义 方案设计思考 POC验证 背景 当前，s3客户端在写底层存储的时候是直接写入远端对象存储，由于写远端时延相对会较高，所以为了提升性能，引入了写本地缓存盘方案。也即要写底层存储时，先把数据写到本地缓存硬盘，然后再把本地缓存 硬盘中的数据异步上传到远端对象存储。 方案设计© XXX Page 3 int loadAllCacheReadFile() {}; private: std::string CacheReadDir_;© XXX Page 8 of 9 }; 方案设计思考 本地硬盘如何管理 借用linux本地文件系统进行管理，存储进本地硬盘的内容以文件的形式来表现。 配置一个目录用于本地硬盘的文件管理，对作为缓存盘的本地硬盘进行格式化并挂载到该目录(如

key_value_pairs 其他说明 实现 1、inode、entry 的编码 2、KVStore Q&A 单靠 redis 的 AOF 机制能否保证数据不丢失? redis 的高可用、高可扩方案？ redis + muliraft 存在的问题？ redis 改造 vs 自己实现? redis 中哈希表实现的优点？ 参考 前言 根据之前讨论的结果，元数据节点的架构如下图所示，这里涉及到两部分需要持久化/编码的内容： 无法保证数据 100% 不丢失（这主要是 redis 基于性能考量，毕竟纯内存数据库，如果利用 WAL 每次写文件再 sync，那么性能就会下降很多） 所以，单靠 redis 的方案是不行了. redis 的高可用、高可扩方案？ 主要是 redis cluster + 主从复制 (或者第三方 codis + 哨兵) redis cluster/codis 主要解决扩展性的问题，它会进行分片，每个

Page 2 of 15 背景 相关调研 moosefs chubaofs 方案设计思考 1.Trash机制是实现1个(类似chubaofs)，还是2个（类似moosefs）？ 2. Trash放在哪里？ 3. 是否需要做session机制（在metaserver打开），来维护inode的打开情况？ 方案设计 Trash机制： Session机制： 遗留问题 工作量评估 背景 sefs复杂，需要引入一些额外的复杂性。 由于是按目录管理trash，那么必须是两个trash（其中一个是reserve）以区分两种不同的情况。 chubaofs chubaofs的方案如下： chubaofs实现了类似trash的机制，称为freelist， 当inode被unlink时，client会发送UnlinkInodeRequest， 对应的metasever接收到 。 我们的整个架构设计本身就类似chubao方式，这个方案本身是chubaofs的成熟方案，说明是已经被验证过是可行的方案。 缺点： 由于link、unlink等接口涉及跨服务器的两个请求的处理，可能会存在孤儿inode的问题，这一情况，chubaofs是通过运维手段去修复，见遗留问题。moosefs由于单mds，不存在这个问题。 方案设计思考 首先我们可以确定以下几个设计点：

的是提供一个通用的文件系统，能够支持海量的文件，这就需要文件系统的元数据有扩展能力。元数据管理仅使用一台元数据管理服务器是不够的。使 用多台元数据服务器需要对元数据进行合理的分片。 当前的一个可行方案是按照inodeid进行分片。分片算法如何设计，热点如何解决下半年细化，当前简单按照算法为 serverid = (inodeid / inode_per_segment) mod metaserver_num inode B dentry信息 0 + A → 100 100 + D → 400 200 + E → 300 0 + B → 200 这里rename的时候，涉及到inode信息跨节点迁移。需要引入分布式锁，是个难点。 symbolic link： 这个类型的文件和普通文件一样创建删除，区别在于，在inode信息中记录需要链接到的地址。 hardlink：生成一个hardlink dentry信息 [{"C", 300}, {"D", 400}] inode 300，查询"C"的inode信息。 inode 400，查询"D"的inode信息。 5.1.2 好处 这种方案的好处在于，inode和dentry大概率落到一个分片上管理。在查询inode的过程中，第一步通过parentid和name查询inodeid，第二步通过inodeid查询inode结构体在同一个分片上处理。查询时，client只

CURVE I/O 抖动Curve文件存储 1. 元数据服务 2. 高性能 3. 可扩展易运维 4. 云原生 设计目标Curve文件存储 1. 兼顾性能与容量的机器学习 场景 2. 快速跨云弹性发布的业务 3. 低成本大容量需求的业务 4. 中间件冷热数据自动分离 5. S3和POSIX统一访问需求 主要挑战和支持场景Curve Roadmap 1. 架构 1. 文件存储支持分布式缓存、完善冷热数据分层存储能力 文件存储支持分布式缓存、完善冷热数据分层存储能力 2. 完善混合云、公有云上部署架构 3. 完善高性能3副本存储引擎，支持混合盘 4. 文件存储支持数据存储到HDFS、rados等引擎 2. 性能 1. 完善RDMA/SPDK方案，发布稳定版本 2. 更高性能硬件选型、适配及性能调优 3. 大文件读写性能优化，RAFT优化，降低写放大 3. 功能 1. 文件存储支持回收站/生命周期管理/配额/用户权限等 2. 支持

MySQL数据库的架构设计和运维。 既熟悉数据库的，是最早的Oracle 9i的OCP，又懂开 发，精通C、python。 唐成（网名osdba）-3- @ 专业的PostgreSQL数据库管理平台 CLup介绍CLup产品介绍 网络 clup-agent 数据库主机1 clup-agent 数据库主机2 clup-agent 数据库主机n  CLup是什么？  实现Po 环境中使用CLup创建Polardb的情况  天翼云 共享盘：所有虚拟机都 可以挂载 有VIP 机器有反亲和性  华为云 有共享盘 有VIP 机器有反亲和性  移动云 共享盘：所有虚拟机都 可以挂载 有VIP 机器有弱反亲和性  腾讯云 无共享盘 VIP是内测阶段 机器的反亲和性：不清 楚  联通云 无共享盘 有VIP