© XXX Page 1 of 9 Curve支持S3 数据缓存方案© XXX Page 2 of 9 版本 时间 修改者 修改内容 1.0 2021/8/18 胡遥 初稿 背景 整体设计 元数据采用2层索引 对象名设计 读写缓存分离 缓存层级 对外接口 后台刷数据线程 本地磁盘缓存 关键数据结构 详细设计 Write流程 Read流程 ReleaseCache流程 Flush流程 FsSync流程 后台流程 poc测试验证 背景 基于s3的daemon版本基于基本的性能测试发现性能非常差。具体数据如下： 通过日志初步分析有2点原因© XXX Page 3 of 9 1.append接口目前采用先从s3 get，在内存中合并完后再put的方式，对s3操作过多 2.对于4k 小io每次都要和s3交互，导致性能非常差。 因此需要通过Cache模块解决以上2个问题。 能的合并后flush到s3上，在读场景上，能够预读1个block大小，减少顺序读对于底层s3的访问频次。从这个思路上该缓存方案主要针对的场景是顺序写和顺序 读，而对于随机写和随机读来说也会有一定性能提升，但效果可能不会太好。 元数据采用2层索引 由于chunk大小是固定的（默认64M），所以Inode中采用map3ChunkInfoList> s3ChunkInfoMap用

© 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 init流程 write流程 read流程 整体架构 S3ClientAdaptor模块：负责将文件数据进行chunk，以及block的拆分为s3的object，并写入/读取s3的object。 S3-allocator模块：负责分配s3-object唯一标识。© XXX Page 3 of 11 整体思路 curvefs对接s3和对接volume主要的区别在于数据持久化和空间分 ，以及空间分配申请（s3不需要释放空间，可 直接删除对应s3 object） 文件首先会按照chunk进行拆分，每个chunk固定64M/1G（待定），chunk内部会划分为多个block，每个block最大4M，每个block对应s3上一个object。 s3上对象已chunkid_indexblock_version进行命名，元数据则已S3ChunkInfo（见

© XXX Page 1 of 9 Curvefs-S3 本地写缓存盘方案© XXX Page 2 of 9 背景 方案设计 主要数据结构定义 方案设计思考 POC验证 背景 当前，s3客户端在写底层存储的时候是直接写入远端对象存储，由于写远端时延相对会较高，所以为了提升性能，引入了写本地缓存盘方案。也即要写底层存储时，先把数据写到本地缓存硬盘，然后再把本地缓存 硬盘中的数据异步上传到远端对象存储。 硬盘中的数据异步上传到远端对象存储。 方案设计© XXX Page 3 of 9 S3模块接收到写入后先写入写内存缓存页，如果满足持久化的条件后，那么则准备持久化。 如果未配置本地硬盘作为写缓存，那么直接持久化到远端的对象存储；如果配置了本地硬盘作为写缓存，那么则尝试先写入本地硬盘写缓存目录。 写本地硬盘缓存目录之前先判断缓存目录容量是否已达到阈值，如果已经达到阈值，那么则直接写入到远端对象存储；否则，则写入 TraverseCacheWriteFile(){}; /** * @brief after client rebootupload the file that store in disk to s3. */ int UploadAllCacheWriteFile(); std::vector wait_for_upload; bthread::Mutex

© XXX Page 1 of 3 curvefs s3数据整理(合并碎片、清理冗余)© XXX Page 2 of 3 1. 2. 3. 1. 2. 3. 4. 5. 6. 1. 2. 背景 只考虑单客户端, 单metaserver 为了解决的问题: 客户端在对一个文件的某个部分多次写入后, 同一个chunk会产生很多版本数据; 而客户端在读的时候 得到有效的部分, 越是散乱的状态, 就越需要发送更多次读请求至s3. 最后导致无效旧数据的堆积和读请求性能的下降, 所以需要在合适的时候进行重叠元数据和数据的合并 原则是尽力而为, 并不能做到完美 方案 基于一下3个基础的数据结构, 2层索引 s3chuninfolist[index] = [s3chunkinfo(s)] s3chunkinfo { chunkid version version // write always 0, compact will increase it offset len } s3 object命名: chunkid_version_index (index为obj在chunk内的index) 执行步骤 数据整理作为一个后台服务(线程池), 运行于metaserver, 遍历metaserver的inode进行数据整理的尝试

overall architecture, data organization and topology structure of CURVE. CurveBS uses the central node Metadata Server (MDS) to manage virtual disk mapping and data replicas distribution. persists the data in ETCD l Collect cluster status and schedule. 2. Chunkserverl Responsible for data storage l Multi-replicas consistency 3. The client l Provides read and write data interfaces with the chunkServer to read and write data 4. Snapshotcloneserver l Independent of core services l Snapshot data is stored in object storage which supports S3 apis. Therefore, there is no limit

protocol to maintain consistency of stored data. It generally takes the form of 3 replicas of data. If one replica fails, the system can read and write data successfully on the other two replicas. When Assume that the total number of disks in Curve system is N, the number of replicas is R, and the data recovery Time in the case of failed disks is T. The Annual Failure Rate of disks is AFR, and the the data on one disk is distributed in about 50 copysets, which means when a disk fails, up to 50 other disks will restore the data on that disk at the same time. According to this, the data recovery

systemUse Cases • Container • Database • Data apps(middleware/bigdata/ai) • Data backupContainer • Aggregates underlying storage in the cloud (AWS EBS, AWS S3, AWS Glacier, aliyun EBS, aliyun OSS) container-native storageDatabase • Database services orchestrated in the cloud • Curve can backup / sync data to slave cloud • When master cloud failure happens, Database service can move to the slave access data by POSIX interface • Infrequent data is moved to OSS, and frequent data is moved to high speed storage transparentlyData backup • Curve (CurveBS, CurveFS) can backup data to remote

快照是云盘数据在某个时刻完整的只读拷贝，是一种便捷高效的数据容灾手段， 常用于数据备份、制作自定义镜像、应用容灾等。 • 快照的特点 • 转储到s3对象存储 • 异步转储快照，底层使用copy-on-write技术，读写不影响转储 • 增量转储，第一次全量转储s3之后，后续只需转储增量部分 • 高可用，快照任务中断自动拉起继续转储快照和克隆的特点 • 克隆的定义 • 克隆是指从卷复制出卷的功能，提供快速的复制卷的能力。 模块，实现快照和克隆的具体功能。 SnapshotCore & CloneCore:快照克隆服务器架构 • SnapshotDataStore负责管理快照转储的数据块，通过调用 S3Adaptor（一个封装了s3 client的接口层）与S3交互，存取s3 中的对象。 SnapshotDataStore: • SnapshotCloneMetaStore负责管理快照和克隆任务等元数据， 通过调用etcdcl • 3.向mds查询快照的元数据，转储快照元数据 块metaObject。 • 4.根据快照元数据信息，转储快照数据块 dataObject。 • 5.调用mds接口，移除curve内部的快照。 • 6.mds调用chunkserver接口，删除内部快照 数据 快照流程： chunk chunk chunk chunkserver meta object data object

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信息 据分片的对应关系。© XXX Page 3 of 19 2、chubaofs的元数据管理 chubaofs（补充链接）的元数据也是采用的raft的方式进行管理，可以借鉴一下chubaofs的元数据的分片策略。 通过分析chubaofs的源代码。chubaofs的用volume管理一个文件系统，每个volume有若干meta partition和data partition。meta partition管理的元数据，data partition管理的元数据，data partition管理数据。meta partition管理inode和dentry信息。 创建一个文件系统时，如何初始化meta partition？ master\cluster.go， chubaofs的文件系统使用volume的来表示，在创建一个文件系统的时候，会创建3个meta partition和10个data partition。chubaofs的data par

Problems for stateful apps ○ storage capacity expansion ○ capacity imbalance ○ apps bundled with data locations ● Requirements for elastic block storage ● Requirements for file systemopen-source storage algorithm cluster with 1200 disks (each have MTBF 1.2 million hours) 3 replicas Restore data on a disk within 5 minutes Data availability of 6 nines can be achievedCloud native Support Currently algorithm ● Raft Consistency protocol High performance ● pre-created file pool ● data strip like RAID ● Zero data copy ● RDMA Cloud NativeCluster topology The physical pool is used to physically