curvefs copyset与fs对应关系 |版本|时间|修改者|修改内容| |---|---|---|---| |1.0|2021/7/23|陈威|初稿| |1.1|2021/8/4|陈威|根据评审意见修改| |1.2|2021/8/9|陈威|增加详细设计| • 1、背景 • 2、chubaofs的元数据管理 • 2.1、meta partition的创建 • 2.2、meta partition的管理 partition的管理 • 2.3、meta partition和inode以及dentry的对应关系? • 3、curvefs的copyset和fs的对应关系 • 3.1 如何获取inodeid • 3.2 copyset fs共用吗? • 3.3 copyset个数是否可以动态调整? • 4、curvefs的topo信息 • 5、curvefs mds和metaserver的心跳 • metaserver 子模块拆分 8、inode和dentry的内存估算 - 8.1 一台机器上能存放多少个inode和dentry - 8.2 一台机器上建议的copyset数量 - 8.3 每个copyset建议管理存储容量的大小 ## 1、 背景 curvefs使用raft作为元数据一致性的保证。为了提高元数据的可扩展性和并发处理能力，采用元数据分片的方式管理ino

Each node in the figure represents a data node (ChunkServer). A CopySet is the basic unit of data replication in CurveBS. A CopySet contains multiple chunks. Copysets in CurveBS are created in advance advance. When users write data, they only need to select an appropriate CopySet and create a new chunk. Why use a CopySet to manage data? 1. Reduce metadata. If the replication group membership is saved for and the communication traffic between replication groups is heavy. Once a CopySet is introduced, it can be explored with CopySet granularity. 3. Improve data reliability. If the replication group is excessively

replicas CopySet1 Node1, Node5, Node7 CopySet2 Node4, Node6, Node9 CopySet3 Node2, Node3, Node8 CopySet4 Node2, Node7, Node9 CopySet5 Node1, Node3, Node6 CopySet6 Node4, Node5, Node8 |$ CopySet\_{1} CopySet\_{1} $|$ Chunk\_{1} $|$ Chunk\_{2} $|……| |---|---|---|---| |$ CopySet\_{2} $|$ Chunk\_{3} $|$ Chunk\_{4} $|……| |$ CopySet\_{3} $|$ Chunk\_{5} $|$ Chunk\_{6} $|……| |……|……|……|……| ## CurveBS Topology ![Imag a7fbb256d/p6_1.jpg) ## MetaData Server(MDS) ## MDS Master Heartbeat Scheduler TopoUpdatet CopySet Scheduler ConfGenerator Leader Scheduler HealthyChecker Replica Scheduler Recover Scheduler

Service层是对外提供的一些RPC服务的接口。包含的RPC服务有： • ChunkService。IO相关操作 • CliService。成员变更相关操作 - CopySetService。创建copyset等操作 - RaftService。Braft内置的service，完成raft成员之间的选举，日志复制，安装快照等操作。  ## ChunkServer架构 Metric统计模块使用brpc中的bvar计数器，统计一些IO层面和copyset层面的一些指标，方便监控和跟踪。  operator: copyset1 change peer CS1 to CS2, etc. 8 When no copyset onCS1, set retired  ## 坏盘（CS1对应的盘）后的迁移流程 初始状态，copyset1，co

chunk -> copyset -> chunk in 3 chunkserver ## raft复制组 每个raft实例用一个copyset管理，copyset是个逻辑概念。写入chunk的数据，由copyset对应的raft完成3副本的写入。 • multi-raft: copyset和chunkserver是多对多的关系 • 每个copyset由3个chunkserver组成 r组成 • 每个chunkserver可以服务多个copyset  ## Curve块存储RAFT应用 ## 请求处理流程 ## 以写请求为例： 1. Client 发送写请求给 Leader ChunkServer。 2. ChunkServer 76004167d358c0c35fe8/p18_3.jpg) ## Curve文件存储RAFT应用 ## Curve文件系统与Curve块存储的实现区别 - Curve文件系统也是使用copyset管理。 • 写日志的方式与Curve块存储基本一致，实现细节略有差异。 - raft apply和raft snapshot的实现和Curve块存储不同。 metaserver有两套存储引

• 例 1：rename A→B（A 存在，而 B 不存在） • 例 2：rename A→C（A 存在，而 C 存在） • 4. 当 2 个操作的 dentry 属于同一个 copyset 有什么不一样？ ## 背景 当前 curvefs 并没有实现 rename 接口，本文档是对 rename 接口实现的调研及方案设计。 rename 操作，主要操作的是 dentry，如 srcDentry，dstDentry 所在 copyset 的 txid 都加 1（这一步是通过 etcd 的事务保证的），如果上一步或这一步失败，因为 txid 不变，原始数据版本也在，还是保证原子性（其实就是一个 txid 对应一个版本的数据） - 下次访问的时候，带上对应 copyset 的最新 txid (copyset_txid)，判断 PendingTx，如果 (copyset_txid >= PendingTxId dentry 副本是一一对应的，下面有机制确保，每个 copyset 只需要一个 PendingTx（即整个 copyset 中最多只会存留一个副本 dentry） ## 下面是图中流程说明： - (1) mount 的时候将 MDS 中所有 copyset 对应的 txid 缓存在本地 - (2) 以 (copyset txid+1) 去对应的 copyset 删除/创建/修改 dentry •

• Topology: 管理集群的 topo 元数据信息。 • Nameserver: 管理文件的元数据信息。 • Copyset: 副本放置策略。 - Heartbeat: 心跳模块。跟chunkserver进行交互，收集chunkserver上的负载信息、copyset信息等。 • Scheduler: 调度模块。用于自动容错和负载均衡。 ## TOPOLOGY topology用于 o配置文件： 集群有一个物理pool，由3个zone组成，每个zone有1台server。 在物理pool上，还创建了一个逻辑pool，逻辑pool使用3个zone，采用3副本，有100个copyset。 cluster_map: servers: - name: server1 internal: 192.168.0.1 internalport: 8200 external: aeff/p10_3.jpg) ## COPYSET Curve系统中数据分片的最小单位称之为Chunk。在大规模的存储容量下，会产生大量的Chunk，如此众多的Chunk，会对元数据的存储、管理产生一定压力。因此引入CopySet的概念，CopySet类似于ceph的pg。CopySet可以理解为一组复制组，这组复制组的成员关系完全一样。CopySet的概念在文献「Copysets: Reducing

e> ## 数据组织形式 • CopySet 类似Ceph中的PG「Copysets: Reducing the Frequency of Data Loss in Cloud Storage」 • 逻辑概念 • 包含多个chunk • 减少元数据数量 • 数据放置的基本单元 减少复制组数量 • 提高数据可靠性 ## Node A CopySet 0Chunk 0Chunk 1Chunk 2 CopySet 1Chunk 3Chunk 4Chunk 5 CopySet 2Chunk 6Chunk 7Chunk 8 ## Node B CopySet 0Chunk 0Chunk 1Chunk 2 CopySet 3Chunk 9Chunk 10Chunk 11 CopySet 4Chunk 12Chunk 13Chunk 14 ## Node C CopySet 0Chunk 0

|---|---| |Disk failure|| |Server failure|| |Server fake death|| |Slow response|1| ## OID + CN ### Copyset allocation algorithm cluster with 1200 disks MTBF 1.2 million hours 3 replicas ## Data availability OID + CND ## Key designs used by CURVE High availability and reliability • Cluster topology • CopySet pre-allocation algorithm • Raft Consistency protocol High performance • pre-created file pool |copset|replicas| |---|---| |$ CopySet\_{1} $|$ Node\_{1}, Node\_{5}, Node\_{7} $| |$ CopySet\_{2} $|$ Node\_{4}, Node\_{6}, Node\_{9} $| |$ CopySet\_{3} $|$ Node\_{2}, Node\_{3}, Node\_{8} $| |$ CopySet\_{4} $|$ Node\_{2}

[Image](/uploads/documents/0/e/f/1/0ef1f0b7a8a77e750b629ec14870d49c/p6_1.jpg) metaserver：元数据服务进程。一个进程管理多个复制组 copyset：复制组，使用 raft 保证数据一致性。复制组中保存文件系统的部分元数据信息 文件系统元数据和复制组是多对多的关系 1. 一个复制组可以包含多个文件的元数据信息 1. 复制组 wal 记录元数据操作 filename-dentryInfo 信息 3. copyset 启动的时候根据 inode 和 dentry 分别建立对应的内存结构，再回放 wal 日志完成构建 ## 卷的元数据管理 卷的元数据中需要包含建立在该卷之上的文件系统元数据分片的位置，以便进行元数据的索引 常见的元数据操作 1. Create 1. 与 mds 交互获取 inode 和 dentry 的 copyset 位置 2. 创建 inode dentry ### 2. Mkdir 1. 与 mds 交互获取 inode 和 dentry 的 copyset 位置 2. 创建 inode 3. 创建 dentry ### 3. Lookup (/A/B) 1. 与 mds 交互获取 /(inodeid=1) 所在的 copyset 2. 根据 parent-inode=1 和 name=A 获取对应的 dentry，从而获取到