IOTracker：跟踪一个上层IO请求  IOSplitor：IO转换拆分  ChunkClient、CliClient：与Chunkserver进行通信  前者负责IO请求  后者负责获取复制组(copyset)的leader  MDSClient：负责与MDS交互，挂卸载卷、获取元数据信息 CLIENT整体架构QEMU： 实现了QEMU block与Client的对接层 向c IO处理：转换、拆分、合并  元数据获取及缓存  逻辑chunk与物理chunk映射关系  物理chunk所属的复制组(copyset)  复制组所在的chunkserver列表  复制组的leader信息  Failover支持  MDS：只有主MDS才会监听端口  ChunkServer：通过raft维护复制组内的主-从关系CLIENT IO流程 用户下发一个写请求 16M 请求落在两个逻辑chunk上，所以 请求会被拆分成两个子请求：  ChunkIdx 1, off: 8M len 8M  ChunkIdx 2, off: 0 len 8MCLIENT IO流程 子请求由哪个chunkserver处理，依赖以 下信息：  逻辑chunk与物理chunk映射关系  物理chunk所属的复制组(copyset)  复制组所在的chunkserver列表

1. 2. 3. metaserver: 元数据服务进程。一个进程管理多个复制组 copyset: 复制组，使用 raft 保证数据一致性。复制组中保存文件系统的部分元数据信息 文件系统元数据和复制组是多对多的关系 一个复制组可以包含多个文件的元数据信息 复制组 wal 记录元数据操作 定期 snapshot 对 wal 进行清理。snapshot 中存储的是键值对，其中 XXX Page 8 of 14 快照的cow© XXX Page 9 of 14 优势在于可以做lazy-copy，速度很快。 劣势在于当前的快照逻辑复用需要做较大变动 方案二：文件系统快照 复用当前的逻辑，文件系统快照就是当前卷的快照，因此数据的快照就已经有了，需要的就是元数据的快照。© XXX Page 10 of 14 1. 1. 2. 3. 2 apply的时候是以kv的方式写入到文件，因此可以复用这个逻辑。 客户端感知文件版本号。如果版本号变更，就触发raft的sanpshot，并且只apply小于版本号的部分 这种方式相当于每次都是全量缓存当前元数据，不做增量快照，考虑到转储逻辑，这也是可以接受的 对比这两种方案，第一种方案对于copy场景是友好的，但需要重新实现一套快照逻辑；第二种方案的改动和实现相对简单，并且对于需要备份的场

归属一个于server。 • Chunkserver: 用于抽象描述物理服务器上的一块物理磁盘 (SSD)，chunkserver以一块磁盘作为最小的服务单元。TOPOLOGY curve在上物理pool之上又引入逻辑pool的概念，以实现统一存储系统的需求，即在单个存储系统中多副 本PageFile支持块设备、三副本AppendFile（待开发）支持在线对象存储、AppendECFile（待开发）支持 近线对象存储可以共存。 隔离（待开发）。TOPOLOGY Topology的实际例子，右侧是topo配置文件： 集群有一个物理pool，由3个zone组成，每个zone有1台server。 在物理pool上，还创建了一个逻辑pool，逻辑pool使用3个zone，采用 3副本，有100个copyset。 cluster pool1 zone1 zone2 zone3 server1 server2 server3 192 h的pg。CopySet 可以理解为一组复制组，这组复制组的成员关系完全一样。CopySet的概念在文献「Copysets: Reducing the Frequency of Data Loss in Cloud Storage」提出。 在 Curve 系统引入 CopySet 有几个目的： 1. 减少元数据量：如果为每个Chunk去保存复制组成员关系，需要至少 ChunkID+3×NodeID=20

redis 的方案是不行了. redis 的高可用、高可扩方案？ 主要是 redis cluster + 主从复制 (或者第三方 codis + 哨兵) redis cluster/codis 主要解决扩展性的问题，它会进行分片，每个 redis 实例保存分片的 key 主从复制主要解决高可用，一个分片实例挂 2 个从实例，当主节点挂掉时，cluster/哨兵会自动将从节点升为主节点 实例需要独立的快照并不合适 如果改造 redis，初步评估了下，其工作量要比自己实现持久化的逻辑要大一些，改造主要是为了让 redis 提供单独 dump/load 一个 DB 的功能： 如果改造，dump/load 的逻辑都得动，而且会牵扯到一些其他逻辑（如主从复制，因为 redis 主从全量复制发送的就是一整个 RDB 文件，即使我们不需要这个功能，这部分代码也是有耦合的）© XXX Page Page 11 of 12 1. 2. 3. 如果自己实现，只是一个简单的 sava/load 逻辑，比较清晰 redis 中有许多数据结构可供使用，如 (哈希、列表、set、sort_set)，但对于目前的需求来说，我们内存数据结构使用的是 C++ STL 中的哈希表（unsorted_map），之后有可能根据需求换成 B+ 树或跳表，但是 redis 中的这些数据结构我们是不需要的

raft和braft 03 raft在Curve中的应用 05 Q&A 04 Curve对raft的优化RAFT协议简介 什么是raft • raft 是一种新型易于理解的分布式一致性复制协议，由斯坦福大学的Diego Ongaro和John Ousterhout提出，《In Search of an Understandable Consensus Algorithm(Extended • raft可以解决分布式理论中的CP，即一致性和分区容忍性 • 大多数副本成功即可返回成功 • 速度取决于写的较快的大多数RAFT协议简介 • Leader：负责从客户端接受日志，把日志复制到其 他服务器，当保证安全性的时候告诉其他服务器应用 日志条目到他们的状态机中。 • Candidate: 发起选举。获取大多数选票的候选人将 成为领导者。 • Follower: 响应来自其他服务器的请求，如果接受不 raft任期RAFT协议简介 raft复制状态机 1. leader收到客户端的请求。 2. leader把请求指令记录下来，写入日志，然后并⾏发 给其他的服务器，让他们复制这条⽇志。 3. 当这条⽇志条⽬被安全的复制，leader会应⽤这条⽇ 志条⽬到它的状态机中。 4. 然后把执⾏的结果返回给客户端。 • 提供命令在多个节点之间有序复制和执行，当多个节 点初始状态一致的时候，保证节点之间状态一致。

CliService。成员变更相关操作 • CopySetService。创建copyset等操 作 • RaftService。Braft内置的service， 完成raft成员之间的选举，日志复制， 安装快照等操作。 ChunkServer架构CopysetNode封装了braft的Node，并 实现了braft的状态机，完成与raft的交 互。详细交互流程后面展开。 CopysetNodeManager负责管理 erver的IO 请求进行并发控制，对上层的读写请 求安照chunk粒度进行Hash，使得不同 chunk的请求可以并发执行。 ChunkServer架构DataStore是对chunk落盘逻辑的封装。 包含chunkfile的创建、删除，以及实际 对chunk的读写，chunk基本cow的快照， 克隆chunk的管理等等。 ChunkServer架构LocalFileSystermAdaptor是对底层文件 CS3收到change peer from CS1 to CS2的operator，给CS2同步 raft日志，当CS2成功赶上进度时，本次raft成员变更成功完成， CS2成为了复制组的一员，CS1不再属于这个复制组。 ⑦ CS3在下一次心跳中向MDS报告本次raft成员变更已完成 ⑧ MDS在得知CS1上的所有copyset都成功迁移后，把CS1设置为 retired，CS1下线完毕。

PageFile/AppendFile/AppendECFile • Segment • 逻辑概念，空间分配的基本单元 （减少元数据数量） • 多个连续地址空间chunk（物理文件）的聚合数据组织形式 • CopySet • 逻辑概念 • 减少元数据数量 • 数据放置的基本单元 • 提高数据可靠性 • 包含多个chunk • 减少复制组数量 类似Ceph中的PG 「Copysets: Reducing

partition（除了最后一片）管理的inode id的个数为2^24，最后一片metapartition管理剩下的一直到2^63-1的Inode id。创建meta partition的时候，选择的3个meta node组成一个复制组。如何选择？论文上写的是按照存储节点的memory和disk usage来选的，通常选择内存和disk使用率最低的节点。 并去对应的meta node上去创建对应的meta partition。 最后一个partition是[100, max]，切完之后，变成了[100， 200]， [200, 分裂 max]。怎么维持一定数目的meta partition数据，目前还没在代码里找到对应的逻辑。 2.3、meta partition和inode以及dentry的对应关系？© XXX Page 5 of 19 怎么确定inode和dentry于partition的对应关系？ 创建in →server：代表着一台服务器 →metaserver：代表着一块盘© XXX Page 9 of 19 每个copyset的由处于不同zone的metaserver组成复制组。 5、curvefs mds和metaserver的心跳 curvefs的mds和metaserver之间的心跳类似于curve块设备的心跳。metaserver需要定期通过心跳向mds上报

te技术，读写不影响转储 • 增量转储，第一次全量转储s3之后，后续只需转储增量部分 • 高可用，快照任务中断自动拉起继续转储快照和克隆的特点 • 克隆的定义 • 克隆是指从卷复制出卷的功能，提供快速的复制卷的能力。 • 这里的克隆还包括从快照回滚的功能 • 克隆的特点 • 支持Lazy和非Lazy两种模式克隆 • 支持从快照克隆和从镜像（卷）克隆 • 支持从快照回滚 • 高可 4KBCHUNKSERVER端快照实现-写时复制原理  写时复制通常使用版本号实现  复制时仅复制元数据，并增加版本号  写入时，先复制要写入的数据块，然后再写入CHUNKSERVER端快照实现-写时复制  使用copy-on-write  当前写请求的sn > chunk的cur_sn时触发复制  拷贝的单位是一个Page，即4KB  使用snapfile中的bitmap标记复制过的PageCH 从临时目录rename，用户可见。 Lazy Alloc Chunk，利于超售： Lazy克隆不直接分配chunk，而是等到client来写 时才分配chunk 额外接口： 不进行数据复制，而是提供额外的Flatten接口， 完成数据复制。 适用场景： 适用于从镜像快速创建云主机场景 非Lazy克隆 较慢，分钟级： Cloned状态可用，即完成整个数据克隆，才从临 时目录rename，用户才可见。

2, osd.3 对ObjectID进行哈希并取模（复制组数量）得到pgid head_D35c9011 根据 offset, len, name.. 生成ObjectID rbd\udata.6855c174a277a30.000000000005c2架构简介 — 多副本一致性协议 复制策略 • 主动拷贝、链式复制、splay复制 异常处理 • PG有23种状态：Peering，Degraded等 空间分配的基本单元 Chunk: 数据分片 Copyset: 复制组 ChunkServer: 管理一个磁盘进程架构简介 — 数据放置 Copyset的放置 Chunk的分配 • 由中心节点MDS以Scatter-width 均衡为目标进行创建 • 由中心节点MDS在各Copyset中 根据权重进行选择架构简介 — 一致性协议 复制策略 • 主动拷贝，由 leader 向 follower