CephF概述

经典文件系统概述

索引式文件系统将底层存储数据的磁盘空间切分为块并为每个文件对象所占用所有块建立一个索引表进行统一存放在一个称为“元数据区”的空间中

索引表就是块地址数组，每个数组元素就是块的地址，于是，一个文件对象的块可以分散存储到离散块空间中
索引表的索引结构称为inode，用于索引、跟踪一个文件对象的权限、隶属关系、时间戳和占据的所有的块等属性信息，不过却不包括文件名和文件内容本身

文件名及其隶属的目录层级关系通过Dentry进行描述

每个Dentry就像一个映射表，它保存了本级目录或者文件名以及紧邻的下一级目录或者文件的名称与各自inode的映射关系
而Dentry自身也需要由专用的inode对象承载，它也拥有自己的inode，于是这种映射便可组织出多级别层次来，这个多级别的层次起始于一个惟一的称之为“根”的起始点，从而形成一个树状组织结构

1.1 CephFS

CephFS用于为RADOS存储集群提供一个POSIX兼容的文件系统接口

• 基于RADOS存储集群将数据与元数据IO进行解耦

• 动态探测和迁移元数据负载到其它MDS，实现了对元数据IO的扩展

• 第一个稳定版随Jewel版本释出

• 自Luminous版本起支持多活MDS（Multiple Active MDS） 特性

  目录分片
  动态子树分区和子树绑定（静态子树分区）
  支持内核及FUSE客户端
  其它尚未稳定特性还包括内联数据（INLINEDATA）、快照和多文件系统等

1.2 MetaData Server

MDS自身并不会直接存储任何数据，所有的数据均由后端的RADOS集群负责存储，包括元数据，MDS本身更像是一个支持读写的索引服务CephFS依赖于专用的MDS（MetaData Server）组件管理元数据信息并向客户端输出一个倒置的树状层级结构

• 将元数据缓存于MDS的内存中

• 把元数据的更新日志于流式化后存储在RADOS集群上

• 将层级结构中的的每个名称空间对应地实例化成一个目录且存储为一个专有的RADOS对象

1.3 MDS

负责检测元数据服务器(MetaData Server)的状态变化的系统组件,处理来自CephFS相关的请求命令
MDS自身并不会直接存储任何数据，所有的数据均由后端的RADOS集群负责存储，包括元数据，MDS本身更像是一个支持读写的索引服务

• CephFS依赖于专用的MDS（MetaData Server）组件管理元数据信息并向客户端输出一个倒置的树状层级结构

• 将元数据缓存于MDS的内存中

• 把元数据的更新日志于流式化后存储在RADOS集群上

• 将层级结构中的的每个名称空间对应地实例化成一个目录且存储为一个专有的RADOS对象

1.4 Multi MDS

多主MDS模式是指CephFS将整个文件系统的名称空间切分为多个子树并配置到多个MDS之上，不过，读写操作的负载均衡策略分别是子树切分和目录副本

• 将写操作负载较重的目录切分成多个子目录以分散负载

• 为读操作负载较重的目录创建多个副本以均衡负载子树分区和迁移的决策是一个同步过程，各MDS每10秒钟做一次独立的迁移决策，每个MDS并不存在一个一致的名称空间视图，且MDS集群也不存在一个全局调度器负责统一的调度决策

• 各MDS彼此间通过交换心跳信息（HeartBeat，简称HB）及负载状态来确定是否要进行迁移、如何分区名称空间，以及是否需要目录切分为子树等

• 管理员也可以配置CephFS负载的计算方式从而影响MDS的负载决策，目前，CephFS支持基于CPU负载、文件系统负载及混合此两种的决策机制

1.5 元数据分区

文件元数据的工作负载通常是一类小而密集的I/O请求,因此很难实现类似数据读写I/O的扩展方式
分布式文件系统提供了将名称空间分割治理的解决方案,通过将文件系统根树及其热点子树分别部署于不同的元数据服务器进行负载均衡,从而赋予了元数据存储线性扩展的可能

例如:某个MDS出现故障新的MDS需要去先接管他所拥有的Rank数据缓存到自己的数据中这需要一个过程,一般解决方案给每一个MDS都做主备方案,或者有公共的MDS在某MDS坏的时候迅速接管,最好的方案做主备在线同步以便出问题可以即时的替换无卡壳(多活MDS)

• 静态子树分区 -> 通过手工分区方式，将数据直接分配到某个服务节点上，出现负载不均衡时，由管理员手动重新进行分配
• 静态Hash分区
• 惰性混编分区
• 动态子树分区 -> 基于静态根据负载情况动态的合理分配mds接管的元数据

在采用动态子树分区法的基础上，CephFS为了达到最佳的扩展性和性能，将元数据和业务数据进行了分离，并且统一存储到RADOS层。存储海量数据的RADOS实际上是基于Hash计算方法来实现的，刚才我们描述过元数据其实不太适合使用Hash这种方式进行存储，那为什么CephFS的元数据仍然使用基于Hash方式的RADOS层来保存呢？原因在于：CephFS元数据访问并不是直接从RADOS层获取，而是存在一个元数据缓存区，其中元数据基于动态子树分区的方式进行分配，因此元数据落盘方式则显得无关紧要，为了简化设计以及利用RADOS的共享存储功能，缓存中的元数据最终落盘于RADOS层，则成为最优选择

Multi MDS

简述

每一个CephFS都有一个容易读的文件系统名称和一个称为FSCID的标识符ID,并且每一个CephFS默认情况下都只配置一个Active MDS守护进程

• 一个MDS集群中可处于Active状态的MDS数量的上限由Max_mds参数设置,它控制可用的Rank数量,默认为1

  <1> rank指CephFS上可同时处于Active状态的MDS守护进程的可用编号,其范围从0到max_mds-1
  <2>一个rank编号意味着一个可以承载CephFS层级文件系统目录子树的元数据管理功能的Active状态的Ceph-mds守护进程的编制,max_mds的值为1意味着仅仅有一个0号的rank可用
  <3>第一次启动的ceph-mds守护进程没有接管任何rank,它在之后的由mon按需求进行分配
  <4>一个ceph-mds一次仅可以占有一个rank,并且在守护进程终止时将其释放

  一个人rank可以有3种状态

  Rank状态	相关描述
  Up	rank已经由某一个ceph-mds守护进程接管
  Failed	rank未被任何ceph-mds守护进程接管
  Damaged	rank处于损坏状态,其元数据处于崩溃丢失状态,在 管理员修复问题并对其运行的ceph mds repaired命令前,处于损坏状态的rank不能分配给其它的任何MDS使用

负载调度方式

多主MDS模式是指CephFS把整个文件系统的名称空间切分为多个子树并且分配到多个MDS上,但是读写操作的负载策略是子树切分和目录副本.

子树分区和迁移的策略的决策是一个同步的过程各个MDS每过10秒做一次独立的迁移决策,每一个MDS并不存在一个一致的名称空间视图,并且MDS集群也不存在一个全局调度器负责统一调度决策,各个MDS彼此之间通过交换心跳信息,及其负载状态来确定是否要进行迁移/如何划分名称空间,以及是否需要目录切分子树

将写操作负载较重的目录切分成多个子目录以分散负载
为读操作负载较重的目录创建多个副本来均衡负载
管理员可以配置CephFS负载的计算方式从而影响MDS的负载决策,当前    版本支持基于CPU负载/文件系统负载/混合负载等决策机制

MDS机制

动态子树分区依赖于共享存储完成热点负载在MDS间的迁移,于是Ceph将MDS的元数据存储于后面的RADOS集群上的专用存储池中,这个存储池可以多个MDS共享

• MDS对于元数据的访问并不直接基于RADOS进行,而是为其提供一个基于内存的缓存区以缓存热点元数据并且在元数据相关日志条目过期之前将一直存储在内存之中

容错问题

CephFS使用元数据日志来解决容错问题

• 元数据日志信息流,存储于CephFS元数据存储池中的元数据日志文件上,类似于LFS(Log-Structured File
  System)/WAFL(Write Anywhere File Layout)的工作机制
• CephFS元数据日志文件的体积可以无限增长以确保日志信息能够顺序的写入RADOS,并且额外赋予守护进程修剪冗余或不相关的日志条目的能力

原文链接：https://bk.poph163.com/2019/11/01/cephfs%E6%96%87%E4%BB%B6%E5%AD%98%E5%82%A8%E7%B3%BB%E7%BB%9F/