© XXX Page 1 of 15 curvefs client 删除文件和目录功能设计© XXX Page 2 of 15 背景 相关调研 moosefs chubaofs 方案设计思考 1.Trash机制是实现1个(类似chubaofs)，还是2个（类似moosefs）？ 2. Trash放在哪里？ 3. 是否需要做session机制（在metaserver打开），来维护inode的打开情况？ 遗留问题 工作量评估 背景 目前curvefs client版本对删除unlink和rmdir的设计只有简单的删除inode和dentry结构，遗留了nlink和lookup count相关的内容还未实现，是不完备的。本文首先调研moosefs，chubaofs等分布式系统，参考并设计解决上述遗留问题。 当前删除接口代码如下：© XXX Page 3 of 15 CURVEFS_ERROR } return ret; } 存在两个问题: 一是删除时nlink字段未考虑： 文件的nlink用于实现hard link。 hard link使用nlink字段表示文件的link的引用计数，第一次创建文件是nlink字段为1。每创建一个新的指向该文件的hard link时,nlink字段+1， 每删除一个hard link或指向的原文件时，nlink字段-1。© XXX Page

MDS使用election模块的功能进行选主 4.1 Curve中MDS的选举过程 4.2 图示说明选举流程 4.2.1 正常流程 4.2.2 异常情况1：MDS1退出，可以正常处理 4.2.3 异常情况2：Etcd集群的leader发生重新选举，MDS1未受影响，可以正常处理 4.2.4 异常情况3：Etcd的leader发生重新选举，MDS1受到影响退出，不一定可以正常处理。 4.2.4.1 LeaseTIme MDS1、MDS2、MDS3的租约全部过期 4.2.4.4 总结 4.2.5 异常情况四: Etcd集群与MDS1(当前leader)出现网络分区 4.2.5.1 事件一先发生 4.2.5.2 事件二先发生 4.2.6 异常情况4：Etcd集群的follower节点异常 4.2.7 各情况汇总 1. 需求 mds是元数据节点，负责空间分配，集群状态监控，集群节点间的资源均衡等，mds故障可能会导致client端无法写入。 需要解决的问题就是：如何确定主备节点。 2. 技术选型 提供配置共享和服务发现的系统比较多，其中最为大家熟知的就是zookeeper和etcd, 考虑当前系统中mds有两个外部依赖模块，一是mysql， 用于存储集群拓扑的相关信息；二是etcd，用于存储文件的元数据信息。而etcd可以用于实现mds高可用，没必要引入其他组件。 使用etcd实现元数据节点的leader主要依赖于它的两个核心机制: TTL和CAS。TTL(time

成为领导者。 • Follower: 响应来自其他服务器的请求，如果接受不 到消息，就变成候选人并发起一次选举。 • 时间被划分成一个个的任期，每个任期开始都是一次 选举。 • 选举成功，领导⼈会管理整个集群直到任期结束。 • 选举失败，这个任期就会没有领导⼈⽽结束。 raft选举leader raft任期RAFT协议简介 raft复制状态机 1. leader收到客户端的请求。 2. le 点初始状态一致的时候，保证节点之间状态一致。 raft日志复制RAFT协议简介 raft配置变更 • 配置：加入一致性算法的服务器集合。 • 集群的配置不可避免会发生变更，比如替换宕机的机器。 直接配置变更可能出现双主问题 • 共同一致（joint consensus） • 集群先切换到一个过渡的配置(old + new)，一旦共同一 致已经被提交，系统切换到新的配置(new)。RAFT协议简介 日志压缩 日志压缩 • 日志会不断增长，占用空间 • 采用快照的方式压缩日志 • 在某个时间点，整个系统的状态都以快照的形式写入 到稳定的持久化存储中 • 完成一次快照之后，删除时间点之前的所有日志和快 照。BRAFT简介 • raft协议提出之后，涌现出了非常多的实现，比如etcd，braft，tikv等。 • braft是raft的一个实现，实现了raft的一致性协议和复制状态机，而且提供了一种通用的基础库。基

03 04 ChunkServer架构 ChunkServer核心模块 新版本ChunkServer性能优化CURVE基本架构 • 元数据节点 MDS • 管理和存储元数据信息 • 感知集群状态，合理调度 • 数据节点 Chunkserver • 数据存储 • 副本一致性，raft • 客户端 Client • 对元数据增删改查 • 对数据增删改查 • 快照克隆服务器CURVE基本架构 封装了braft的Node，并 实现了braft的状态机，完成与raft的交 互。详细交互流程后面展开。 CopysetNodeManager负责管理 CopysetNode的创建、初始化、删除等 ChunkServer架构心跳模块有两方面的职责： 1、向MDS节点上报心跳，心跳中包括 ChunkServer本身的一些统计信息 2、解析MDS的心跳response中的raft 成 请求进行并发控制，对上层的读写请 求安照chunk粒度进行Hash，使得不同 chunk的请求可以并发执行。 ChunkServer架构DataStore是对chunk落盘逻辑的封装。 包含chunkfile的创建、删除，以及实际 对chunk的读写，chunk基本cow的快照， 克隆chunk的管理等等。 ChunkServer架构LocalFileSystermAdaptor是对底层文件 系统的一层抽象，目前适配封装了ext4

应关系 curvefs的元数据的分片，需要考虑到在创建inode的时候，其实是不知道inodeid的，在创建完成之后，才有inodeid。inodeid的分配最好下放到各个分片去进行处理。否则整个集群的inode都去一个地方获取id会 造成巨大的锁开销，这个是不能接受的。 curve块设备的元数据管理，在分配数据的时候，offset一开始就是知道的，这是和curvefs分配很大的一个不同点。 copyset 带来的copyset数量过多影响性能的问题。 3.3 copyset个数是否可以动态调整？ 根据copyset个数是否可以动态调整，有两种实现。 一种是curve块存储方案，在集群初始化的时候，把所有的copyset创建好。采用这种方式， 可以采用hash的方式去确定inode的分片。比如说， ， copysetid = (fsid + inodeid << shift ) ode分配完了，转为readonly状态，随着文件和目录的删除，copyset管理的元数据会越来越少。类chubaofs方案的均衡问题如何解决? CopySetScheduler: copyset均衡调度器。根据集群中copyset的分布情况生成copyset迁移任务； LeaderScheduler: leader均衡调度器。根据集群中leader的分布情况生成leader变更任务； ReplicaScheduler:

存目录后，从本地硬盘读目录© XXX Page 4 of 9 做一个硬链接链接到该文件。 本次io在本地硬盘写入好之后，异步上传模块会适时把本地硬盘写缓存目录中的文件上传到远端对象存储集群，上传成功后，删除本地写缓存目录中的对应文件。 同时，缓存清理模块会定时检查本地硬盘缓存目录容量情况，如果容量已经达到阈值了，则进行文件的清理工作。 另外，异常管理模块处理客户端挂掉后的文件重新上传问题。 本地缓存盘存放的文件即是存储到对象存储中的对象。 写缓存如何作为读缓存利用 除了写缓存目录，另外引入读缓存目录；当写缓存目录中有新文件加入时，则对该文件做硬链接到读缓存目录。 这样，写缓存目录中的文件上传完之后就可以直接删除了，那么该文件的读缓存还是存在的。 缓存盘空间管理 当缓存文件内容达到阈值时，停止向本地缓存盘写入。 同时，缓存清理模块会定时检查本地硬盘缓存目录容量情况，如果容量已经达到阈值了，则进行文件的清理工作。 理工作。 本地缓存盘的异步上传 工作队列: 该队列中保存缓存盘中的待上传文件名 工作线程: 遍历工作队列(队列swap)，从缓存盘目录读取到文件内容并上传到对象存储。文件上传到对象存储后，直接删除。 工作队列做好互斥管理 异常管理 如果客户端挂掉，那么写缓存盘中可能会有残留文件没有上传到对象存储；如果忘记处理，那么这些数据也就相当于是丢失了。 所以在客户端初始化建立的时候，可以先遍历

许超杰CURVE基本架构 01 02 03 04 快照和克隆的特点 快照克隆服务器架构 快照的实现 05 克隆的实现CURVE基本架构 • 元数据节点 MDS • 管理和存储元数据信息 • 感知集群状态，合理调度 • 数据节点 Chunkserver • 数据存储 • 副本一致性，raft • 客户端 Client • 对元数据增删改查 • 对数据增删改查 • 快照克隆服务器 • 块metaObject。 • 4.根据快照元数据信息，转储快照数据块 dataObject。 • 5.调用mds接口，移除curve内部的快照。 • 6.mds调用chunkserver接口，删除内部快照 数据 快照流程： chunk chunk chunk chunkserver meta object data object data object S3 Snap Task 获取快照元数据 datastore metastore http service clone Task user 快照元数据 2.创建内部快照 5.删除内部快照 快照数据 1.发起快照 SnapshotCloneServer 6.删除内部快照数据快照的元数据和数据组织 字段 类型 说明 uuid string 快照唯一Id user string 所属用户 fileName string

中的哈希实现很独立，单独的文件 t_hash.c，其性能表现也非常好） redis 哈希表实现主要优点参考以下 总的来说，我们只是参考 redis 持久化实现，而 redis 中的大头（各类数据结构、模块化、主从复制、集群等这些都是我们目前不需要的），因此去改造 redis 感觉不是很划算 redis 中哈希表实现的优点？ 主要是当哈希表需要扩桶的时候，rehash 过程中 redis 采用了均摊/渐进式的思想，把 ht[1] 两个哈希表 (2) 在字典中维持一个索引计数器变量 rehashidx, 并将它的值设置为 0, 表示 rehash 工作正式开始 (3) 在 rehash 进行期间, 每次对字典执行添加、删除、查找或者更新操作时, 程序除了执行指定的操作以外, 还会顺带将 ht[0] 哈希表在 rehashidx 索引上的所有键值对 rehash 到 ht[1], 当 rehash 工作完成之后, 程序将 哈希表渐进式 rehash 执行期间的哈希表操作： 因为在进行渐进式 rehash 的过程中, 字典会同时使用 ht[0] 和 ht[1] 两个哈希表, 所以在渐进式 rehash 进行期间, 字典的删除 (delete)、查找(find)、更新(update) 等操作会在两个哈希表上进行: 比如说，要在字典里面查找一个键的话，程序会先在 ht[0] 里面进行查找，如果没找到的话，就会继续到 ht[1]

com/cw123/curve/tree/fs_s3_joint_debugging 环境：test2 1. 启动curvefs 手动创建curve卷，/etc/curve/client.conf中配置卷所在集群信息。 启动服务&client挂载卷：bash startfs.sh start volume (挂载目录为/tmp/fsmount)© XXX Page 3 of 33 # wanghai 仅设置在目录的其他用户权限位的执行权限上。如果在某个目录上的权限设置为多个用户都拥有写权限，那就意味着凡是拥有写权限的用户都能直接管理该目录中的所有文件名，包括改名文件及删除文 件名等操作；因此需要在这样的目录上设置STICKY特殊权限；如果此类目录设置了STICKY，则所有用户即便拥有写权限，也仅能删除或改名所有者为其自身的文件； # STICKY # chmod o+t DIR # chmod 1777 DIR nbs@pubbeta1-nostest2:/tmp$ conf中增加配置项‘user_allow_other’）启用内核基于mode的权限控制。 2：新建rootinode mode = 1777（原因是设置STICKY，避免普通用户对非自己所属文件的删除） 3：这样达到的效果除了不支持ACL外与正常本地文件系统权限管理一致（一般情况下使用ACL极少，且从抓取的传媒接口调用发现并未涉及相关接口的调用）。 参考文献： https://www

• 元数据节点 MDS 管理元数据信息 收集集群状态信息，自动调度 • 数据节点 Chunkserver 数据存储 副本一致性 • 客户端 Client 对元数据增删改查 对数据增删改查 • 快照克隆服务器MDS各个组件 MDS是中心节点，负责元数据管理、集群状态收集与调度。MDS包含以下几个部分： • Topology: 管理集群的 topo 元数据信息。 • Nameserver: 通过结合curve的用户系统，LogicalPool可以通过配置限定特定user使用的方式，实现多个租户数据物理 隔离（待开发）。TOPOLOGY Topology的实际例子，右侧是topo配置文件： 集群有一个物理pool，由3个zone组成，每个zone有1台server。 在物理pool上，还创建了一个逻辑pool，逻辑pool使用3个zone，采用 3副本，有100个copyset。 cluster 信息更新拓扑 中的信息。 • ConfGenerator: 将当前上报的 copyset 信息提交给调度模块， 获取该 copyset 上可能需要执行的任务。 • HealthyChecker: 检查集群中的 chunkserver 在当前时间点距 离上一次心跳的时间，根据这个时间差更新chunkserver状态。 Chunkserver端：chunkserver 端的心跳由两个部分组成： •