Ceph 文件系统客户端的驱逐

当某个文件系统客户端不响应或者有其它异常行为时,有必要强制切断它到文件系统的访问,这个过程就叫做驱逐

驱逐 CephFS 客户端,就是防止它再与 MDS 和 OSD 守护进程通讯。如果客户端已经对文件系统的缓冲 IO 做了些操作,这些未刷回的数据会丢失。

客户端也有可能被自动(如果它们没及时与 MDS 通讯)、或手动驱逐(被系统管理员)。

客户端驱逐机制适用于所有类型的客户端,包括 FUSE 挂载客户端、内核挂载客户端、 nfs-ganesha 网关、以及其它使用 libcephfs 的进程。

自动驱逐客户端

在三种情况下,客户端会被自动驱逐:

  1. 在一个活跃的 MDS 守护进程上,如果一个客户端在限定的时间 session_autoclose (一个文件系统变量)秒数(默认 300 秒)内没有与 MDS 通讯,它就会被自动驱逐。

  2. 在一个活跃的 MDS 守护进程上,如果一个客户端在限定的时间 mds_cap_revoke_eviction_timeout (配置变量)秒数(默认 300 秒)内没有回应 cap 撤销消息。默认已禁用。

  3. 在 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_staletrue ,以此为客户端重连提速。

高级话题:配置黑名单功能

如果由于客户端主机慢或者网络不可靠,频繁遇到客户端驱逐,这些底层问题还解决不了,你可以让 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 上进行的。