6-21 1,272 views
在Ceph中,他们建立了一套独特的系统来管理客户端对Inode的操作权限,称为capabilities,简称CAPS。与其他网络文件系统(例如NFS或SMB)的主要区别之一是授予的CAPS非常精细,并且多个客户端可能在同一个inode上拥有不同的CAPS。
有一些“通用”的cap位,表示这些cap所赋予的是何种能力。
/* generic cap bits */ #define CEPH_CAP_GSHARED 1 /* client can reads (s) */ #define CEPH_CAP_GEXCL 2 /* client can read and update (x) */ #define CEPH_CAP_GCACHE 4 /* (file) client can cache reads (c) */ #define CEPH_CAP_GRD 8 /* (file) client can read (r) */ #define CEPH_CAP_GWR 16 /* (file) client can write (w) */ #define CEPH_CAP_GBUFFER 32 /* (file) client can buffer writes (b) */ #define CEPH_CAP_GWREXTEND 64 /* (file) client can extend EOF (a) */ #define CEPH_CAP_GLAZYIO 128 /* (file) client can perform lazy io (l) */
然后将它们移位特定数量的比特。这些表示正在授予cap的是inode数据或元数据的哪一部分:
/* per-lock shift */ #define CEPH_CAP_SAUTH 2 /* A */ #define CEPH_CAP_SLINK 4 /* L */ #define CEPH_CAP_SXATTR 6 /* X */ #define CEPH_CAP_SFILE 8 /* F */
只有某些通用cap类型会被做某些移位。特别是,只有FILE移位有超过前两位。
通过上面的操作,我们得到了一些常量,这些常量是通过取每个位值并移位到正确的位而生成的,例如:
#define CEPH_CAP_AUTH_SHARED (CEPH_CAP_GSHARED << CEPH_CAP_SAUTH)
然后可以将这些位组合在一起以形成表示一组能力的位掩码。
有一个例外:
#define CEPH_CAP_PIN 1 /* no specific capabilities beyond the pin */
“pin”只是将Inode固定到内存中,而不会授予任何其他cap。
图形描述:
+---+---+---+---+---+---+---+---+ | p | _ |As x |Ls x |Xs x | +---+---+---+---+---+---+---+---+ |Fs x c r w b a l | +---+---+---+---+---+---+---+---+
第二位当前未使用。
每个CAP授予的能力
● Pin — p Inode存在于内存中
● Auth — A 身份认证元数据:mode, uid, gid
● Link — L Inode的链接计数(有多少个dentries链接到这个Inode)
● Xattr — X Inode的扩展属性,它们的存在这件事本身和它们的值
● File — F 文件数据,文件大小,最后修改时间等
● Shared — s 作为很多个拥有对这个状态的共享访问权限的client中的一个
● Exclusive — x 这个客户端是唯一能访问这个状态的(独占)
● Read — r 客户端能读取这个状态
● Write — w 客户端能写入这个状态
● Cache — c 客户端能在本地缓存这个状态
● Buffer — b 客户端能在本地缓冲写入变更
● 不是每个cap都用到所有许可
● pin:二元的,客户端能否记得Inode的存在
● Auth, Link, Xattr:共享(s)或独占(x)
● [ALX]s — 能保存状态到本地以供查阅
○ 我们能在客户端检查权限
● [ALX]x — 没有其他人能查看这个状态,我们“拥有”它
○ 我们可以在本地更改元数据而稍后再通知MDS!
● 不是每个cap都用到所有许可
● Fs:可以本地缓存并读取最后修改时间,文件大小
● Fx:可以本地写入最后修改时间,文件大小
● Fr: 可以读取文件数据(和OSD同步)
● Fc:可以缓存文件数据以供本地读取
● Fw:可以写入文件数据(和OSD同步)
● Fb:可以缓冲写入数据,在后台刷新
CAPS来自MDS
● MDS是元数据的最终权威
●每块元数据由一个锁控制(“simplelock”、“scatterlock”,“filelock”)决定如何共享该状态
○ 副本MDS有某些客户端没有的权限
○ 哪个cap能被授予哪些客户端
● 客户端发送元数据更新和cap获取请求
●大量的启发式方法根据这些输入改变锁定状态,以尝试和优化
CAPS如何变更?
● MDS可以对不同的客户端授予或撤销caps
○ 通常是由于别的客户端的活动导致
● 对于撤销的情况,客户端必须停止使用这个cap,并向MDS发生MClientCaps信息确认这一变更
○“停止使用”可能很容易也可能很困难:如果它是缓存或共享读取,仅仅只要丢弃数据并变更状态
○ 对缓冲写入等来说,客户端必须刷新掉所有脏数据——可能会花费大量时间!
CAP架构带来的后果
● MDS必须记住所有客户端固定的东西
○ 它必须追踪所有客户端
● 所以你的MDS的缓存必须比所有客户端的缓存还要大
● 因为caps是合作式的,需要工作或访问权限的客户端可能被别的客户端所阻挡
一些健康警告
客户端没有响应cap释放请求
● MDS已经发送cap撤销信息但是客户端没有返回
● 可能的原因:
○ 网络或OSD繁忙
○ 客户端收到了很多撤销信息,没有办法及时刷新所有
○ 软件Bug
○ 恶意用户
○ 客户端由于某些原因运行缓慢
● 默认60秒后打印这一信息
● mds_cap_revoke_eviction_timeout
(默认: 0,关闭) 能设置为强制断开没有响应的客户端
客户端没有响应缓存压力
● MDS已经要求客户端释放一些固定住的Inode来减少内存使用,但是客户端没有释放足够的量
● 可能的原因:
○ 可能客户端非常活跃并且需要用到所有固定住的元数据,没有办法释放更多
○ 网络或OSD繁忙
○ 软件Bug
○ 恶意用户
○ 客户端由于某些原因运行缓慢
● 这个警告是一个非常复杂的衰减计数器,基于客户端释放caps的速率与它必须释放的速率的对比
- Ceph客户端缓存一致性分析 - 2019年6月21日
- CephFS:什么是CAPS? - 2019年6月21日
- Ceph集群快速搭建教程 - 2019年6月20日