Curve文件系统空间分配方案如果合并之后是一个完整的块,则重新将level1中对应的bit置为0,同时删除该extent。 如果不能合并,则向level2中插入一个新的extent。 小文件处理 大量小文件的情况下,按照上述的分配策略,会导致level1的bitmap标记全为1,同时level2中也会有很多extent。 所以可以参考chubaofs,对大小文件区分不同的分配逻辑。同时,将文件系统的空间划分成两个部分,一部分用 文件在第一次申请空间时,选择一个能满足要求的extent分配出去。后续的空间申请,同样要带上文件最后一个字节所在的地址空间,用于尽量分配连续的地址空间。 文件空间的申请,具体由大文件,还是由小文件处理,可以参考如下策略,大小文件阈值为1MiB:© XXX Page 6 of 11 并发问题 如果所有的空间分配和回收全部由一个分配器来进行管理,那么这里的分配很有可能成为一个瓶颈。 为了避免整个问题,可以将整个 空间回收时,根据回收的offset,交给对应的分配器去回收。© XXX Page 7 of 11 文件系统扩容 在线扩容时,直接在新扩容的空间上,创建新的空间分配器进行空间管理。 文件系统重新加载时,再将所有的空间,按照上述的策略,进行分组管理。 接口设计 RPC接口 当前设计是把空间分配器作为内置服务放在元数据节点,所以请求的发起方是fuse client,元数据服务器接收到请求后,根据fsId查找到对应的文件系统的0 码力 | 11 页 | 159.17 KB | 6 月前3
Curve核心组件之mds – 网易数帆MDS是中心节点,负责元数据管理、集群状态收集与调度。MDS包含以下几个部分: • Topology: 管理集群的 topo 元数据信息。 • Nameserver: 管理文件的元数据信息。 • Copyset: 副本放置策略。 • Heartbeat: 心跳模块。跟chunkserver进行交互,收集chunkserver上的负载信息、 copyset信息等。 • Scheduler: 调度模块。用于自动容错和负载均衡。TOPOLOGY Mds在分配空间时,轮流在不同的copyset中分配,每次从copyset中分配1个chunk, 这个chunk用copysetId:chunkId来唯一标识。COPYSET Copyset的生成策略:Source code : curve/src/mds/copyset/ bool GenCopyset(const ClusterInfo& cluster, int numCopysets 定时任务由调度模块定时触发。 • 触发任务由外部触发,管理员通过工具触发。 • TopoAdapter 用于获取Topology中调度需要使用的数据。 • Common Strategy 是通用的副本添加和移除策略。 任务管理: 任务管理模块用于管理计算模块产生的任务。 • operatorController 是任务集合,用于存放和获取任务; • operatorStateUpdater 根据上报的copyset信息更新状0 码力 | 23 页 | 1.74 MB | 6 月前3
CurveFS方案设计改动和实现相对简单,并且对于需要备份的场景也是够用的。从可解决程度和解决的必要性考虑,选择第二种方 案。 关键点 mds volume 文件空间管理 文件系统的元数据所在的copyset分配策略(前期可以考虑都分配到同一个copyset上) metaserver inode/dentry的内存组织形式 数据持久化 client curvefs 的 client 开发 快照逻辑 各接口实现元数据交互流程 inode 和 dentry 的索引设计(btree / skiplist / hashmap ?) 元数据的持久化(以 kv 的方式存入文件?存储 rocksdb ?) 元数据节点的高可用 元数据分片策略(哪些范围的元数据存储在哪些复制组上) 数据结构 在元数据设计上,扁平化元数据(用 parentID+Filename → FileInfo 表示一个文件)和分级元数据(ParentID+Filename 2. 3. 4. 文件空间管理 文件空间管要解决的问题是:一个文件的数据如何存储?物理空间如何分配给不同的文件,如何从不同的文件回收?从这两个角度出发,分别调研了以下系统的空间管理策略: bluestore: CurveFS空间分配调研#bluestore chubaofs: CurveFS空间分配调研#chubaofs moosefs: moosefs空间分配调研 polarfs:0 码力 | 14 页 | 619.32 KB | 6 月前3
CurveFs 用户权限系统调研root@pubbeta1-nostest2:/tmp# cd fsmount bash: cd: fsmount: Permission denied© XXX Page 4 of 33 查阅资料发现这是fuse的一种安全策略,默认是只有filesystem owner拥有该文件系统的访问权限,如果想要其他用户有权访问,需要在挂载参数中指定‘-o allow-root’ 或'-o allow-other'以允许相应用户有 file1 drwxr-xr-x 0 wanghai01 neteaseusers 0 Apr 10 2081 folder fuse默认是不会检查文件访问权限的,它允许在文件系统中自由的实现访问控制策略或将其下放到底层文件访问机制(e.g. in case of network filesystems)。挂载参数‘default_permissions’用于启用内核自己的权限检查,而不是将权限检查 cat hello.txt hello world 结论:fuse挂载时使用'default_permissions' 和 ‘allow_other’ ;或者可以在用户态文件系统中自由的实现访问控制策略。 可以达到共享文件系统下的基于内核权限检查的文件访问控制 二、文件系统权限管理© XXX Page 16 of 33 // example in linux // --------- drwxr-xr-x0 码力 | 33 页 | 732.13 KB | 6 月前3
新一代云原生分布式存储head_D35c9011 根据 offset, len, name.. 生成ObjectID rbd\udata.6855c174a277a30.000000000005c2架构简介 — 多副本一致性协议 复制策略 • 主动拷贝、链式复制、splay复制 异常处理 • PG有23种状态:Peering,Degraded等 • 强一致性协议对异常的容忍较差 使用WARO一致性协议 • 所有副本写完成返回客户端 Copyset的放置 Chunk的分配 • 由中心节点MDS以Scatter-width 均衡为目标进行创建 • 由中心节点MDS在各Copyset中 根据权重进行选择架构简介 — 一致性协议 复制策略 • 主动拷贝,由 leader 向 follower 并发拷贝 异常处理 • 自动leader选举 • 2N+1 副本数可以容忍 N 副本数异常 Quorum一致性协议 • 大多数副本写完成返回客户端0 码力 | 29 页 | 2.46 MB | 6 月前3
CurveFS Copyset与FS对应关系对应关系。© XXX Page 3 of 19 2、chubaofs的元数据管理 chubaofs(补充链接)的元数据也是采用的raft的方式进行管理,可以借鉴一下chubaofs的元数据的分片策略。 通过分析chubaofs的源代码。chubaofs的用volume管理一个文件系统,每个volume有若干meta partition和data partition。meta partition管理的元数据,data 4、和metaserver交互时,request请求需要带上copyset信息。 7.2 mds端 1、需要实现topo模块 2、实现mds和metaserver的心跳 3、实现fs和copyset的分片策略的实现 4、实现出现异常场景下的数据恢复,副本修复的调度。 7.3 metaserver端 1、需要提供copyset的创建功能 2、由copyset负责inode和dentry的管理 30 码力 | 19 页 | 383.29 KB | 6 月前3
TGT服务器的优化例如sheepdog的开发者提交过一个patch,但是测试效果不理想,分析 原因,event loop依然是瓶颈对TGT的性能优化 • IO是使用多个epoll 线程,充分发挥多CPU能力 • 当前策略是每个target一个epoll线程,负责Initiator发过来的I/O • 好处是各target上的CPU使用由OS负责分配,CPU分配粒度更细 • 也可以多个卷的lun都分配到一个target上,这样多个卷共享一个target,0 码力 | 15 页 | 637.11 KB | 6 月前3
Curve支持S3 数据缓存方案Id的目的是为了后续从对象存储上遍历,反查文件,这里就要求inodeId是永远不可重复。 读写缓存分离 读写缓存的设计采用的是读写缓存分离的方案。 写缓存一旦flush即释放,读缓存采用可设置的策略进行淘汰(默认LRU),对于小io进行block级别的预读。 即读写缓存相互没影响不相关, 缓存层级 缓存层级分为fs->file->chunk->datacache 4层,通过inodeId找0 码力 | 9 页 | 179.72 KB | 6 月前3
CurveFS Client 概要设计能快的结构,这里考虑采用hash_map。 2. 由于fuse一次mount是一个独立的进程,因此,不需要考虑在同一个进程中支持多文件系统,每个文件系统对应独立进程。 3. cache应当有淘汰策略,元数据cache如果不淘汰,那么缓存到client端的cache会越来越多,这部分可以采用LRU。 4. 考虑到“dirty” inode和 dentry的flush过程,还需方便的过滤出di0 码力 | 11 页 | 487.92 KB | 6 月前3
Curve文件系统元数据管理5 元数据分片 inode和dentry的组织是按照什么方式进行组织,还有一些因素需要考虑。 是mds节点上组成一个全局的结构体,还是分目录,按照一个目录进行组织。 这需要考虑的元数据管理的分片策略。当前curve文件系统目的是提供一个通用的文件系统,能够支持海量的文件,这就需要文件系统的元数据有扩展能力。元数据管理仅使用一台元数据管理服务器是不够的。使 用多台元数据服务器需要对元数据进行合理的分片。0 码力 | 24 页 | 204.67 KB | 6 月前3
共 10 条
- 1













