原理简述

首先看一下客户端访问CephFS的过程。在CephFS中，客户端是使用CephFS的所有操作请求的入口。客户端将元数据读写请求发送到活跃的MDS，从中获取文件元数据，并且安全地缓存元数据和文件数据。

MDS将元数据提供给客户端，缓存热的元数据是为了减少对后端元数据池的请求，管理客户端的缓存是为了保证缓存一致性。CephFS工作过程是，在活跃的MDS之间复制热的元数据，并将元数据变化信息合并到日志，定期刷新到后端元数据池中，使数据在集群间实时同步，具体如图2-4所示。

详细交互过程

当 Client 打开文件时，客户端向 MDS 发送请求，实际上就是 MDS 向 OSD 定位该文件所在的文件索引节点（File Inode），该索引节点包含一个唯一的数字、文件所有者、大小和权限等其他元数据；

MDS 会赋予 Client 读和缓存文件内容的权限，访问被授权后返回给客户端 File Inode 值、Layout（Layout 可以定义文件内容如何被映射到 Object）、文件大小，

Client 根据 MDS 返回的信息定位到要访问的文件，然后直接与 OSD 执行 File IO 交互；

同样，当客户端对文件执行写操作时，MDS 赋予 Client 带有缓冲区的写权限，Client 对文件写操作后提交给 MDS，MDS 会将该新文件的信息重新写入到 OSD 中的 Object 中；

树状结构

图是个 MDS 树状结构，MDS 集群为了适应分布式缓存元数据的特点，采用了一种叫作动态子树分区（Subtree Partitioning）的策略，Subtree 可以理解为横跨多个 MDS 节点的目录层级结构，MDS 统计一个目录中元数据信息被访问的频繁程度并计数，MDS 还维护了一个称作权重的树，其记录的是最近元数据的负载情况，MDS 会定期的加载并比较前后权重值的大小，然后根据权重值适当地迁移子树以实现工作流分散在每个 MDS 中。访问程度频繁被称为热点的目录还可以进行 Hash 算法后存在多个 MDS 上；

客户端挂载

客户端访问 Ceph FS 主要有分为 Kernel 内核驱动和 Ceph FS FUSE 两种方式，Linux Kernel 2.6.34 开始加入了对 Ceph FS 的原生支持，如果客户端使用的内核版本较低或者一些应用程序依赖问题，也可以通过 FUSE（Filesystem in Userspace）客户端来挂载 Ceph 文件系统；

MDS 需要使用两个 Pool，一个 Pool 用来存储数据，一个 Pool 用来存储元数据。所以，创建 fs_data 和 fs_metadata 两个存储池，一个用来存储数据，另一个存储元数据；