本文发布于Cylon的收藏册,转载请著名原文链接~
Ceph专门提供了文件系统接口CephFS
。CephFS是略微不同于RBD的架构形式,在基础的RADOS Cluster存储集群的基础之上,需要额外运行一个守护进程MDS
MetaDataServer 元数据服务器。
RADOS Cluster
自己是一个对象存储服务,他无法管理传统文件系统上分离去管理元数据和数据的功能。(而且元数据还拥有权限、用户属组、时间戳等。)RADOS Cluster自身是无法实现这个功能的。MDS专用于模拟传统文件系统所应该具有的将数据和元数据分离存储的方式而专门提供的一个服务。MDS只用来管理元数据。
MDS需要工作一个守护进程,客户端必须通过套接字的方式,每一次访问文件时,先去联系到MDS,来获取文件的元数据信息,再到RADOS Cluster以对象方式,将对象模拟成传统文件系统的块,来加载文件数据。
如是挂在CephFS系统的客户端,需先联系到MDS,识别文件系统的各种信息。客户端向挂载目录路径下的任何一个读写操作就相当于由挂载时的内核驱动模块联系到对应的MDS,而后再由客户端之上的模块来联系到RADOS Cluster。为了能够支持CephFS文件系统,也需要内核级模块Ceph.ko模块。挂载过程机制为将内核模块作为文件系统内核的客户端,与文件系统的守护进程进行通讯,必要时将用户数据存取转为对应集群的存储操作。
对于Rados存储集群来讲,存储集群所有数据都会被放在存储池当中,而CephFS管理其数据和元数据分别放置在不同的存储池中。所有元数据都是由MDS管理的。MDS也是客户端,连入CephFS的的metadata,专门用于存储元数据的存储池。
cephfs逻辑
元数据是一类很密集的IO访问。对原数据存储池的操作是放置在存储池当中的,但在本地会使用内存(高速缓存)中完成,过断时间同步到metadata pool中。而数据直接写入data存储池中
meatdata pool只能对mds访问,其他任何客户端时不能被访问的。客户端对元数据的访问必须经由MDS来实现。
当客户端打开一个文本时,首先请求客户端的inode(传统文件系统采用inode来保存文件的元数据)。获得相应授权以后从mds中接收到inode,inode中标示文件的数据究竟放置在data pool的那些对象中。返回对象编号给客户端,客户端基于对象编号访问所有的对象,将数据加载到。
ceph mds stat
mds: 2 up:standby
当没有文件系统时,无法进行选举,故所有的都为standby
CephFS Client访问CephFS集群的方式
- 客户端挂载CephFS,
- 基于内核文件系统完成挂载
ceph
、libcephfs
- 用户空间文件系统(FUSE
Filesystem in USErspace
):libcephfs与ceph集群进行交互。
- 基于内核文件系统完成挂载
==激活CephFS步骤==
-
激活CephFS MDS,至少有一个节点运行ceph-mds守护进程
ceph-deploy
命令完成的
-
创建存储池:metadata-pool、data-pool
ceph osd pool create cephfs_metadata 8 8 ceph osd pool create cephfs_data 8 8
-
激活文件系统:
ceph fs new <name> {metadata-pool-name} {pool-name}
ceph fs status {filesystem-name}
ceph fs stat
-
获得必要授权,才能使用服务
ceph auth get-or-create client.fsclient mon 'allow r' mds 'allow rw' osd 'allow rwx pool=cephfs-data' -o ceph.client.fsclient.keyring
-
客户端挂载
- 客户端挂载时key和用户名要分开两个不通选项来指定的。
$ ceph-authtool -p -n client.fsclient ceph.client.fsclient.keyring AQATNhZdmHEBIBAA52a2MESQJS8mMScxPzRkIA== $ ceph auth print-key client.fsclient AQATNhZdmHEBIBAA52a2MESQJS8mMScxPzRkIA== ceph auth print-key client.fsclient >fsclient.key # 此key文件是被客户端使用的。需要复制到客户端 scp fsclient.key root@172.18.0.6:/etc/ceph
- 确保安装ceph-common客户端
- 确保内核中有ceph模块
ceph.ko
,此模块必须存在才能使用Ceph客户端 - 确定可获取到Ceph集群的配置文件
ceph.conf
。
$ mount -t ceph stor01:6789,stor02:6789,stor03:6789:/ /data -o name=fsclient,secretfile=/etc/ceph/fsclient.key
# stat 跟挂载点可查看文件系统类型
$ stat -f /data
文件:"/data"
ID:cfb80ce541d5e304 文件名长度:255 类型:ceph
块大小:4194304 基本块大小:4194304
块:总计:1061 空闲:1061 可用:1061
Inodes: 总计:0 空闲:-1
如需开机自启动需写入/etc/fstab
下
stor01:6789,stor02:6789,stor03:6789:/ /data ceph name=fsclient,secretfile=/etc/ceph/fsclient.key,_netdev,noatime 0 0
umount /data
mount -a # 自动挂载
如内核级没有提供ceph模块,就无法基于内核文件系统形式挂载和使用ceph客户端, 此时就只能使用ceph-fuse
客户端。
fuse不要求内核级必须有相应的内核模块,但要求在用户空间安装一个程序包ceph-fuse
ceph以用户空间形式的文件系统逻辑来挂载ceph。无需ceph-common并且一样需提供用于认证的客户端账号。
$ ceph-fuse -n client.fsclient -m stor01:6789,stor02:6789,stor03:6789 /data
2019-06-29 16:09:14.537 7f42c9515c00 -1 init, newargv = 0x55baceded440 newargc=7
ceph-fuse[50438]: starting ceph client
ceph-fuse[50438]: starting fuse
注:内核只要支持应该使用内核级,用户空间级的性能上比不上内核级文件系统。
开机自动挂载
none /data fuse.ceph ceph.id=fsclient,ceph.conf=/etc/ceph/ceph.conf,_netdev,default 0 0
CephFS工作模型
文件元数据的工作负载通常是一类小而密集的IO请求,因此很难实现类似数据读写IO那样的扩展方式。
分布式文件系统业界提供了将名称空间分割治理的解决方案,通过将文件系统根树及其热点子树分别存储于不同的元数据服务器进行负载均衡,从而赋予了元数据存储线性扩展的可能
- 静态子树分区,固定的不灵活
- 静态hash分区,对文件名或目录进行hash运算
- 惰性混编分区,将静态hash和传统文件方式混合使用
- 动态子树分区,
Multi MDS
多主MDS模式是指CephFS将整个文件系统的名称空间切分为多个子树并配置到多个MDS之上,不过,读写操作的负载均衡策略分别是子树切分和目录副本
- 将写操作负载较重的目录切分成多个子目录以分散负载
- 为读操作负载较重的目录创建多个副本以均衡负载
子树分区和迁移的决策是一个同步过程,各MDS每10秒钟做一次独立的迁移决策,每个MDS并不存在一个一致的名称空间视图,且MDS集群也不存在一个全局调度器负责统一的调度决策
各MDS彼此间通过交换心跳信息(HeartBeat,简称HB)及负载状态来确定是否要进行迁移、如何分区名称空间,以及是否需要目录切分为子树等
- 管理员也可以配置CephFS负载的计算方式从而影响MDS的负载决策,目前,CephFS支持基于CPU负载、文件系统负载及混合此两种的决策机制
动态子树分区依赖于共享存储完成热点负载在MDS间的迁移,于是Ceph把MDS的元数据存储于后面的RADOS集群上的专用存储池中,此存储池可由多个MDS共享
·MIDS对元数据的访问并不直接基于RADOS进行,而是为其提供了一个基于内存的缓存区以缓存热点元数据,并且在元数据相关日志条目过期之前将一直存储于内存中
CephFS使用元数据日志来解决容错问题 ·元数据日志信息流式存储于CephFS元数据存储池中的元数据日志文件上,类似于LFS(Log-Structured File System)和WAFL(Write Anywhere File Layout)的工作机制, ·CephFS元数据日志文件的体积可以无限增长以确保日志信息能顺序写入RADOS,并额外赋予守护进程修剪冗余或不相关日志条目的能力
每个CephFS都会有一个易读的文件系统名称和一个称为FSCID标识符ID,并且每个CephFS默认情况下都只配置一个Active MDS守护进程
一个MDS集群中可处于Active状态的MDS数量的上限由max_mds
参数配置,它控制着可用的rank数量,默认值为1
- rank是指CephFS上可同时处于Active状态的MDS守护进程的可用编号,其范围从0到
max mds-1
- 一个rank编号意味着一个可承载CephFS层级文件系统==目录子树==元数据管理功能的
Active
状态的ceph-mds
守护进程编制,max_mds的值为1时意味着仅有一个0号rank可用。 - 刚启动的ceph-mds守护进程没有接管任何rank,它随后由MON按需进行分配
- 一个ceph-mds一次仅可占据一个rank,并且在守护进程终止时将其释放;一个rank只能被一个MDS所占用,被占用后其他MDS就不能再使用它了。
- 如果MDS名额数量少于进程数量,多余出来的进程只能处于备用模式。
- 一个rank可以处于下列三种状态中的某一种:
Up
:rank已经由某个ceph-mds守护进程接管Failed
:rank未被任何ceph-mds守护进程接管Damaged
:rank处于损坏状态,其元数据处于崩溃或丢失状态;在管理员修复问题并对其运行ceph mds repaired”命令之前,处于Damaged状态的rank不能分配给其它任何MDS守护进程
当新添加osd时,数据会将pg分配到新的osd上,如果此时影响集群访问。可以添加flag nobackfill:禁止数据回填
,norebalance:禁止重平衡数据。在执行集群维护或者停机时,可以使用该flag
ceph osd set nobackfill # 增加
ceph osd unset nobackfill # 取消
本文发布于Cylon的收藏册,转载请著名原文链接~
链接:https://www.oomkill.com/2019/07/04-1-cephfs/
版权:本作品采用「署名-非商业性使用-相同方式共享 4.0 国际」 许可协议进行许可。