Ceph 文件系统客户端的驱逐¶
当某个文件系统客户端不响应或者有其它异常行为时,有必要强制切断它到文件系统的访问,这个过程就叫做驱逐。
驱逐 CephFS 客户端,就是防止它再与 MDS 和 OSD 守护进程通讯。如果客户端已经对文件系统的缓冲 IO 做了些操作,这些未刷回的数据会丢失。
客户端也有可能被自动(如果它们没及时与 MDS 通讯)、或手动驱逐(被系统管理员)。
客户端驱逐机制适用于所有类型的客户端,包括 FUSE 挂载客户端、内核挂载客户端、 nfs-ganesha 网关、以及其它使用 libcephfs 的进程。
自动驱逐客户端¶
在三种情况下,客户端会被自动驱逐:
在一个活跃的 MDS 守护进程上,如果一个客户端在限定的时间
session_autoclose
(一个文件系统变量)秒数(默认 300 秒)内没有与 MDS 通讯,它就会被自动驱逐。在一个活跃的 MDS 守护进程上,如果一个客户端在限定的时间
mds_cap_revoke_eviction_timeout
(配置变量)秒数(默认 300 秒)内没有回应 cap 撤销消息。默认已禁用。在 MDS 启动(包括故障恢复)期间,它要途径一个名为
reconnect
的状态,在这个状态下,它会等待所有客户端连接到这个新 MDS 守护进程。如果有客户端在限期(mds_reconnect_timeout
,默认 45 秒 )内未能连上,它们就会被驱逐。
以上任何一种情况产生,就会向集群日志发送一条警告消息。
手动驱逐客户端¶
有时候,管理员可能得手动驱逐某个客户端。比如说,一个客户端已死,管理员不想等它的会话超时;或者有个客户端行为异常,管理员又无法登录客户端节点卸载它。
一般要先检查下客户端列表:
ceph tell mds.0 client ls
[
{
"id": 4305,
"num_leases": 0,
"num_caps": 3,
"state": "open",
"replay_requests": 0,
"completed_requests": 0,
"reconnecting": false,
"inst": "client.4305 172.21.9.34:0/422650892",
"client_metadata": {
"ceph_sha1": "ae81e49d369875ac8b569ff3e3c456a31b8f3af5",
"ceph_version": "ceph version 12.0.0-1934-gae81e49 (ae81e49d369875ac8b569ff3e3c456a31b8f3af5)",
"entity_id": "0",
"hostname": "senta04",
"mount_point": "/tmp/tmpcMpF1b/mnt.0",
"pid": "29377",
"root": "/"
}
}
]
找到想要驱逐的客户端后,就可以用它的唯一 ID 、或者其它属性来标识它:
# 这些都可以
ceph tell mds.0 client evict id=4305
ceph tell mds.0 client evict client_metadata.=4305
高级话题:从黑名单踢出客户端¶
通常,进了黑名单的客户端就不能再重新连接服务器了:它必须被卸载、然后再重新挂载。
然而,在某些情况下,还是得允许被驱逐后、又想重连的客户端。
CephFS 是用 RADOS OSD 黑名单来控制客户端驱逐的,所以只要把它们从黑名单删除,就是允许这些 CephFS 客户端重连了:
$ ceph osd blacklist ls
listed 1 entries
127.0.0.1:0/3710147553 2018-03-19 11:32:24.716146
$ ceph osd blacklist rm 127.0.0.1:0/3710147553
un-blacklisting 127.0.0.1:0/3710147553
假如被拉黑的客户端对缓冲 IO 做了操作,而其它客户端访问了这些文件,这样做就可能会破坏数据完整性。而且也不能确定客户端功能会完全恢复——要想挽回一个完全健康的被驱逐客户端,最好的方法是把它卸载掉,然后再干净地挂载。
如果你想这样重连客户端,可以在 FUSE 客户端上设置 client_reconnect_stale
为 true
,以此为客户端重连提速。
高级话题:配置黑名单功能¶
如果由于客户端主机慢或者网络不可靠,频繁遇到客户端驱逐,这些底层问题还解决不了,你可以让 MDS 别那么严格。
对于响应缓慢的客户端,可以简单地丢弃它们的 MDS 会话,却允许它们重新开启会话并且允许它们继续与 OSD 通讯。要打开这种模式,可以在 MDS 节点上把 mds_session_blacklist_on_timeout
设置为
false 。
对于手动驱逐时的类似情形,可以把 mds_session_blacklist_on_evict
设置为 false 。
注意,如果禁用了黑名单功能,那么驱逐客户端只会在收到了命令的 MDS 上生效。在一个多活 MDS 系统上,你得向所有活跃的 MDS 守护进程发送驱逐命令。黑名单功能启用时(默认如此),只要把驱逐命令发给一个 MDS 就足够了,因为黑名单会自动扩散到其余守护进程。
背景: 黑名单和 OSD 元图屏蔽¶
一个客户端被加入黑名单后,有必要确保其它客户端和 MDS 守护进程能收到最新的 OSDMap (新增了这条黑名单的),以免有人再访问那些进了黑名单的客户端访问过的数据对象。
这是通过名为 “osdmap epoch barrier” 的内部机制保证的。
此屏蔽的目的是为了确保当我们分配出这些能力后,别的客户端就有可能触碰同样的 RADOS 对象,接受分配能力的客户端们必须有足够新的 OSD 图,这样它们才不会与取消的操作(来自 ENOSPC )或进了黑名单的客户端(来自驱逐过程)竞争。
更具体些,我们设置元图屏蔽的情形有:
客户端驱逐(此客户端被加入黑名单了、且其它客户端必须等到有加黑之后的元图出现才能触碰同一批对象);
客户端正在处理 OSD 图的完整标识(此客户端可能会在快完整的元图中取消一些 OSD 操作,这样其它客户端都必须等着,直到元图完整或周期达到才能触碰同样的对象);
MDS 启动,因为我们不会永久存储屏蔽图元,所以必须假设重启后总是需要最新的 OSD 图。
注意,为保持简洁性这是个全局值,其实我们可以做到按每索引节点维护此值,但我们没有这么做,因为:
它会复杂得多;
每索引节点需额外多占 4 字节的内存;
无论如何它都不会比大家一直都拥有最新的 OSD 图更有效。而且,大多数情况下,大家都能轻松地越过这个屏障而不是等着它。
我们仅在极少数情形下使用这种屏蔽,所以每索引节点这样细粒度的实现带来的好处也很少见。
元图屏蔽随其它能力消息一起传递,并且可指示消息接收器在看到这个 OSD 元图前、别再向那些 OSD 发送 RADOS 操作。主要是面向客户端(它们直接向文件写入数据)的,也适用于 MDS ,因为像文件尺寸探测和文件删除这样的操作都是直接在 MDS 上进行的。