Ceph的文件系统架构及经常使用实战
Ceph提供了块、对象和文件等多种存储方式，成功了一致存储。前文说过，Ceph的对象存储基于RADOS集群。Ceph的文件系统也是基于RADOS集群的，也就是说Cephfs对用户侧出现的是文件系统，而在其外部则是基于对象来存储的。
CephFS是散布式文件系统，这个散布式从两个方面了解，一个方面是底层存储数据依赖的是RADOS集群；另外一个方面是其架构是CS（客户端-服务端）架构，文件系统的经常使用是在客户端，客户端与服务端经过网络通讯启动数据交互，相似NFS。
如图所示客户端经过网络的方式衔接到Ceph集群，Ceph集群的文件系统映射到客户端，出现为一个本地的目录树。从用户的角度来看，这个映射是透明的。
当然，关于CephFS集群来说，数据并非以目录树的方式存储的。在CephFS中，数据是以对象的方式存储的，文件的访问最终也会转换为（RADOS）对象的访问。
CephFS集群的装置与经常使用
CephFS的装置总体比拟繁难，咱们假定如今曾经有一个Ceph集群了。基于已有的Ceph集群，经过两个关键步骤就可以提供文件系统服务，一个是启动MDS服务，该服务是文件系统的元数据治理服务；另外一个是创立存储数据的存储池资源。
关于CephFS，须要创立2个存储池来存储数据，一个存储池用于存储元数据，另外一个存储池用于存储数据。创立存储池的步骤如下：
ceph osd pool fs_data ceph osd pool fs_metadata ceph fs new cephfs fs_metadata fs_data就这么繁难，而后就可以经常使用该文件系统了。以内核态文件系统为例，其挂载方法与其它文件系统很相似。
mount t ceph :: mntcephfs o o nameadminsecretAQDNnfBcuLkBERAAeNj60btlYt31NSScIRhg假设一切反常，那么在客户端就可以经常使用该散布式文件中的数据了。
CephFS客户端架构
CephFS的客户端有多种成功方式，一种是在Linux内核中客户端成功，还有一种是基于fuse（参考用户态文件系统框架FUSE的引见及示例）的成功。只管是两种不同的成功方式，然而没有实质的区别。
客户端对集群的访问分为两个关键的流程，一个是经过MDS访问集群文件系统的元数据，另一个流程是客户端对数据的访问（读写），这个是客户端间接与RADOS集群的交互。
了解了关于CephFS全体的架构和访问流程，接上去咱们引见一下咱们引见一下客户端的全体架构及关键流程。由于基于FUSE的成功封装了很多细节，全体逻辑还是比拟繁难的，因此咱们临时不引见该成功。咱们先引见一下基于内核的CephFS客户端的成功。
CephFS是基于VFS成功的，因此其全体架构与其它Linux文件系统十分像。如图所示，CephFS的位置与Ext4和NFS的相关如图所示。
CephFS的差异点在于CephFS是基于网络将数据存储在RADOS集群，而不像Ext4一样将数据存储在磁盘上。
假设依照CephFS的逻辑架构来划分，CephFS可以分为如图所示的几层。其中最上方是接口层，这一层是注册到VFS的函数指针。用户态的读写函数最终会调用到该层的对应函数API。而该层的函数会优先（依据性能状况而定）与缓存替换。
页缓存是一切文件系统专用的，并非CephFS独享。咱们暂且将页缓存归为CephFS客户端的一层。以写数据为例，恳求或许将数据写入缓存后就前往了。而缓存数据的刷写并非实时同步的，而是依据适当的机遇经过数据读写层的接口将数据发送进来。
而后是数据读写层，数据读写层成功的是对恳求数据与后端交互的逻辑。关于传统文件系统来说是对磁盘的读写，关于CephFS来说是经过网络对集群的读写。
信息层位于最上方，信息层关键成功网络数据收发的性能。该模块在Linux内核的网络模块中，不只仅CephFS经常使用该模块，块存储RBD也经常使用该模块网络收发的性能。
CephFS集群架构
传统文件系统是经过磁盘数据块来组织文件系统的，数据分为元数据和数据两种类型。其中元数据是治理数据的数据，比如某个文件数据的位置信息或许文件的大小和创立期间等。而数据则是指文件的实践数据，或许目录中的文件或许子目录信息。
CephFS有些差异，由于其底层是RADOS对象集群，其提供的是一个对象的汇合。前面咱们创立文件系统的时刻也看到了，其实是创立了两个对象存储池。因此，CephFS的数据和元数据其实都是以对象的方式存在的。咱们看一下上方实例中创立的文件系统，其实曾经有很多对象了（1.0000000为根目录的元数据对象）。
在客户端的文件系统有一个树型的结构，CephFS组织数据的逻辑方式也是树型结构。为了容纳数据，每个文件系统肯定须要一个根目录，CephFS也是有一个根目录的，这个根目录在前面创立文件系统的时刻创立。根目录的inode ID是1，这个在前面揭示过。
文件存储在目录当中，在CephFS中是以元数据的方式存储的。在CephFS中，目录中的文件是以omap的方式存储的。也就是每个目录会以其inode ID作为称号在元数据存储池创立一个对象，而目录中的文件（子目录）等数据则是以该对象omap的方式存在的，而非对象数据的方式。
例如，咱们在前面创立的文件系统中的根目录创立5个空文件，区分是testa、testb、testc ...等，此时咱们可以在根目录的对象中失掉omap的一切Key信息。
这外面的omap是以KV的方式存在的，其中Value对应的为inode信息，如下是testa对应的inode信息，这些信息包括该文件关键的元数据信息，例如inode ID和创立期间等等。
在Ceph文件系统中，文件的元数据存储在MDS集群中，而数据则是间接与OSD集群交互。以自动性能为了，文件被拆分为4MB大小的对象存储。由于准则确定，当客户端经过MDS创立文件后，客户端可以间接依据恳求在文件中逻辑位置确定数据所对应的对象称号。
文件数据对应的对象称号为文件的inode ID与逻辑偏移的的组合，这样可以依据该对象称号成功数据的读写。
以testa为例，咱们在其中写入16MB的数据，此时可以发生4个对象。经过stat检查testa的inode ID为1099511627776（0x10000000000）。检查一下数据存储池中对象列表如下：
可以看到与该文件相关的对象列表，其前半局部为inode ID，后半局部是文件以4MB为单位的逻辑偏移。
在详细成功层面，Ceph经过如下几个数据结构来示意文件系统中的文件和目录等信息。这些数据结构的相关如图所示。
可以看到这里关键有三个数据结构来保养文件的目录树相关，区分是CInode、CDentry和CDir。上方咱们引见一下这些数据结构的作用。
CInode数据结构
CInode蕴含了文件的元数据，这个跟Linux内核的inode相似，每个文件都有一个CInode数据结构对应。该数据结构蕴含文件大小和领有者等信息。
CDentry数据结构
CDentry是一个粘合层，它建设了inode与文件名或许目录名之间的相关。一个CDentry可以链接到最多一个CInode。然而一个CInode可以被多个CDentry链接。这是由于链接的存在，同一个文件的多个链接肯定称号是不同的，因此须要多个CDentry数据结构。
CDir数据结构
CDir用于目录属性的inode，它用来在目录下建设与CDentry的链接。假设某个目录有分支，那么一个CInode是可以有多个CDir的。
上述类的相关如图所示，其中CDir中存在着一个与CDentry的一对多的相关，示意目录中的文件或许子目录相关。CInode与CDentry则是文件的元数据信息与文件称号的对应相关。
上述数据结构是内存中的数据结构，除了须要耐久化到对象的数据结构，这局部内容本文临时不做引见。
当天咱们大抵的引见了一下CephFS的全体架构，经常使用和集群端的架构。
