Ceph文件系统客户端驱逐

当文件系统客户端无响应或行为不当时，可能需要强制终止其对文件系统的访问。这个过程称为驱逐.

驱逐CephFS客户端可以阻止它与MDS守护进程和OSD守护进程进一步通信。如果客户端正在对文件系统进行缓冲IO，任何未刷新的数据将会丢失。

客户端可能被自动驱逐（如果它们未能及时与MDS通信），或手动驱逐（由系统管理员执行）。

客户端驱逐过程适用于所有类型的客户端，包括FUSE挂载、内核挂载、nfs-ganesha网关以及任何使用libcephfs的进程。

自动客户端驱逐

客户端可能被自动驱逐的情况有三种。

在活动的MDS守护进程上，如果一个客户端在超过session_autoclose（文件系统变量）秒（默认为300秒）后没有与MDS通信，那么它将被自动驱逐。
在活动的MDS守护进程上，如果一个客户端在超过mds_cap_revoke_eviction_timeout（配置选项）秒后没有响应撤销消息，它将被自动驱逐。此功能默认禁用。
在MDS启动期间（包括故障转移时），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或各种其他属性来识别它：

# These all work
ceph tell mds.0 client evict id=4305
ceph tell mds.0 client evict client_metadata.=4305

高级：解除客户端的封禁

通常情况下，被列入封禁列表的客户端可能无法重新连接到服务器：它必须先卸载，然后重新挂载。

然而，在某些情况下，允许被驱逐的客户端尝试重新连接可能是有用的。

由于CephFS使用RADOS OSD封禁列表来控制客户端驱逐，因此可以通过从封禁列表中删除客户端来允许CephFS客户端重新连接：

$ ceph osd blocklist ls
listed 1 entries
127.0.0.1:0/3710147553 2018-03-19 11:32:24.716146
$ ceph osd blocklist rm 127.0.0.1:0/3710147553
un-blocklisting 127.0.0.1:0/3710147553

执行此操作可能会使数据完整性面临风险，如果其他客户端访问了被列入封禁列表的客户端正在执行缓冲IO的文件。此外，这也不能保证客户端完全恢复正常——驱逐后重新挂载客户端是恢复完全健康的最佳方法。

如果您正在尝试以这种方式重新连接客户端，您可能还会发现将client_reconnect_stale设置为true在FUSE客户端中很有用，以提示客户端尝试重新连接。

高级：配置封禁列表

如果您由于客户端主机速度慢或不稳定的网络而频繁驱逐客户端，并且无法解决根本问题，那么您可能希望要求MDS变得不那么严格。

可以通过简单地终止慢速客户端的MDS会话，但允许它们重新打开会话并允许它们继续与OSD通信来应对慢速客户端。要启用此模式，请在您的MDS节点上将mds_session_blocklist_on_timeout设置为false。

对于手动驱逐的等效行为，设置mds_session_blocklist_on_evictthe “kvs” Ceph object class is not packaged anymore. The “kvs” Ceph object class offers a distributed flat b-tree key-value store that

注意，如果禁用封禁列表，则驱逐客户端将仅对您发送命令的MDS生效。在具有多个活动MDS守护进程的系统上，您需要向每个活动守护进程发送驱逐命令。当封禁列表启用时（默认情况下），向单个MDS发送驱逐命令就足够了，因为封禁列表会传播到其他守护进程。

背景：Blocklisting和OSD epoch屏障

客户端被列入封禁列表后，必须确保其他客户端和MDS守护进程在尝试访问任何可能被列入封禁列表的客户端访问的数据对象之前，拥有最新的OSDMap（包括封禁列表条目）。

这是通过内部“osdmap epoch barrier”机制来确保的。

障碍的目的在于确保当我们分发任何可能允许触摸相同RADOS对象的权限时，我们分发给客户端的权限必须具有足够新的OSD地图，以避免与已取消的操作（来自ENOSPC）或被列入封禁列表的客户端（来自驱逐）竞争。

更具体地说，设置epoch barrier的情况包括：

客户端驱逐（客户端被列入封禁列表，其他客户端必须等待封禁列表后的epoch才能触摸相同对象）。

客户端中的OSD地图全标志处理（客户端可能从预全epoch取消一些OSD操作，因此其他客户端必须等到全epoch或之后才能触摸相同对象）。

MDS启动，因为我们不持久化障碍epoch，所以在重启后必须假设始终需要最新的OSD地图。

注意，这是一个全局值，为了简单起见。我们可以按inode维护此值。但我们不这么做，因为：

这会更复杂。

这将使每个inode使用额外的4个字节内存。

这不会更高效，因为几乎总是每个人都有最新的OSD地图。而且，在大多数情况下，每个人都会轻松通过这个障碍而不是等待。

这个障碍在很少的情况下才会执行，因此任何从按inode粒度获得的好处都很少见。

epoch barrier会随着所有权限消息一起传输，并指示消息接收者在看到这个OSD epoch之前不要向OSD发送任何更多的RADOS操作。这主要适用于客户端（它们的数据写入直接到文件），但也适用于MDS，因为诸如文件大小探测和文件删除等操作都是直接从MDS执行的。

由 Ceph 基金会带给您

Ceph 文档是一个社区资源，由非盈利的 Ceph 基金会资助和托管Ceph Foundation. 如果您想支持这一点和我们的其他工作，请考虑加入现在加入.