ceph tell mds.monxx client ls 检查ceph 文件系统挂载和驱逐

admin · 发表于 2022-8-19 17:35:49

ceph tell mds.monxx client ls 检查ceph 文件系统挂载节点
自动驱逐客户端¶
在三种情况下，客户端会被自动驱逐：

在一个活跃的 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 上进行的。

		自动登录	找回密码
密码			注册