cephfs文件系统中客户端的驱逐自动，手动等

admin · 发表于 2022-7-27 13:37:00

Ceph 文件系统客户端的驱逐¶

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

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

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

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

自动驱逐客户端¶在三种情况下，客户端会被自动驱逐：

在一个活跃的 MDS 守护进程上，如果一个客户端在限定的时间 session_autoclose （一个文件系统变量）秒数（默认 300 秒）内没有与 MDS 通讯，它就会被自动驱逐。& b" u7 X# V+ c# L; ~
在一个活跃的 MDS 守护进程上，如果一个客户端在限定的时间 mds_cap_revoke_eviction_timeout （配置变量）秒数（默认 300 秒）内没有回应 cap 撤销消息。默认已禁用。+ p% N0 u/ \- D- {8 ]& Q
在 MDS 启动（包括故障恢复）期间，它要途径一个名为 reconnect 的状态，在这个状态下，它会等待所有客户端连接到这个新 MDS 守护进程。如果有客户端在限期（ mds_reconnect_timeout ，默认 45 秒）内未能连上，它们就会被驱逐。
7 ?' \" R6 I7 m3 R# Q0 @/ w4 l4 S; b* U* X9 l

以上任何一种情况产生，就会向集群日志发送一条警告消息。

手动驱逐客户端¶有时候，管理员可能得手动驱逐某个客户端。比如说，一个客户端已死，管理员不想等它的会话超时；或者有个客户端行为异常，管理员又无法登录客户端节点卸载它。
一般要先检查下客户端列表：
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=4305ceph tell mds.0 client evict client_metadata.=4305

高级话题：从黑名单踢出客户端¶通常，进了黑名单的客户端就不能再重新连接服务器了：它必须被卸载、然后再重新挂载。
然而，在某些情况下，还是得允许被驱逐后、又想重连的客户端。
CephFS 是用 RADOS OSD 黑名单来控制客户端驱逐的，所以只要把它们从黑名单删除，就是允许这些 CephFS 客户端重连了：
$ ceph osd blacklist lslisted 1 entries127.0.0.1:0/3710147553 2018-03-19 11:32:24.716146$ ceph osd blacklist rm 127.0.0.1:0/3710147553un-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 ）或进了黑名单的客户端（来自驱逐过程）竞争。
更具体些，我们设置元图屏蔽的情形有：

客户端驱逐（此客户端被加入黑名单了、且其它客户端必须等到有加黑之后的元图出现才能触碰同一批对象）；/ M8 b1 L0 A, Z# l) f+ ~

客户端正在处理 OSD 图的完整标识（此客户端可能会在快完整的元图中取消一些 OSD 操作，这样其它客户端都必须等着，直到元图完整或周期达到才能触碰同样的对象）；7 I" L2 ]( f0 c9 v/ K

MDS 启动，因为我们不会永久存储屏蔽图元，所以必须假设重启后总是需要最新的 OSD 图。
% {% B; F& W" v P; R" z. A5 c# L- I) ]3 g7 G! ]! b' v

注意，为保持简洁性这是个全局值，其实我们可以做到按每索引节点维护此值，但我们没有这么做，因为：

它会复杂得多；
# P5 v+ {4 u; y7 K
每索引节点需额外多占 4 字节的内存；
3 N6 O _+ t# h& n* Q9 r" u. i
无论如何它都不会比大家一直都拥有最新的 OSD 图更有效。而且，大多数情况下，大家都能轻松地越过这个屏障而不是等着它。" k8 s' N: I1 Z* D

我们仅在极少数情形下使用这种屏蔽，所以每索引节点这样细粒度的实现带来的好处也很少见。* D7 }) ?( Z9 P, d7 w1 s6 u
2 {/ d. R% g- z& h: I0 Z8 j

元图屏蔽随其它能力消息一起传递，并且可指示消息接收器在看到这个 OSD 元图前、别再向那些 OSD 发送 RADOS 操作。主要是面向客户端（它们直接向文件写入数据）的，也适用于 MDS ，因为像文件尺寸探测和文件删除这样的操作都是直接在 MDS 上进行的。

admin · 发表于 2022-7-27 13:37:48

处理占满的 Ceph 文件系统¶
当 RADOS 集群使用率达到总容量的 mon_osd_full_ratio （默认 95% ）时，它会被打上 OSD full 标记。在问题解决前（如扩容集群），此标记会使大多数常规 RADOS 客户端暂停所有操作。

文件系统对 full 标记还有些特殊处理，下文详述。

Hammer 及更高版¶
从 hammer 发布开始，以下行为会导致占满的文件系统返回 ENOSPC 错误：

客户端写入数据

删除和裁剪以外的其它元数据操作

因为只有在数据刷回到硬盘（有时是 write 返回 0 之后）才可能遇到占满的情况，所以应用程序调用 fsync 或 fclose （或等价操作）进行文件处理时才可能遇到 ENOSPC 错误。

调用 fsync 能可靠地反映数据是否写入了硬盘，并且在没写入时返回错误。 fclose 只有在缓冲的数据从上次写入以来被偶尔刷回过才会返回错误［译者：原文可能有误］—— fclose 成功并不能保证数据写入了硬盘，而且在空间占满时， fclose 之后如果没地方存储缓冲的数据，它们就可能被丢弃。

Warning

如果某一应用程序在占满的文件系统上行为异常，有必要检查下它调用了 fsync() 来确保数据已写入硬盘，然后再继续。

如果客户端运行时已经看到了 OSD full 标记，写数据操作可能被取消。各个客户端取消操作并释放文件能力时会更新 osd_epoch_barrier ，以确保这些取消的操作不会妨碍 MDS 或其它客户端对这些数据对象的访问。要了解元图屏蔽机制，请参考背景：黑名单和 OSD 元图屏蔽。

老版本（ hammer 之前）的行为¶
在 hammer 之前的 Ceph 版本中， MDS 会忽略 RADOS 集群的占满状态，而且客户端的任意数据写入都会卡死，直到集群脱离占满状态。

出现这种行为时有两种危险情形要注意：

如果一客户端到一个文件的写入未完成，那么它不可能把文件释放给 MDS 让它删除，这样就很难清理占满的文件系统。

如果客户端持续地创建大量空文件，来自 MDS 的元数据写入操作终将会耗尽 OSD 空间，这样就再也不能执行删除动作了。

admin · 发表于 2022-7-27 13:38:17

故障排除¶
慢或卡住的操作¶
如果遇到了明显的卡顿操作，首先要定位问题源头：是客户端、 MDS 、抑或是连接二者的网络。从存在卡顿操作的地方下手（参考下面的慢请求（ MDS 端）），进而缩小范围。

RADOS 健康状况¶
如果 CephFS 的元数据或者数据存储池的某一部分不可用、且 CephFS 不响应，很有可能是 RADOS 本身有问题，应该先解决这样的问题（故障排除）。

MDS 问题¶
如果某个操作卡在了 MDS 内部，类似 “slow requests are blocked” 的消息最终会出现在 ceph health 里，也可能指出是客户端的问题，如 “failing to respond” 或其它形式的异常行为。如果 MDS 认定某些客户端的行为异常，你应该弄明白起因。常见起因有：

系统过载（如果你还有空闲内存，增大 mds cache size 配置试试，默认才 100000 。活跃文件比较多，超过 MDS 缓存容量是此问题的首要起因！）

客户端比较老（行为异常），或者

底层的 RADOS 问题。

除此之外，你也许遇到了新的软件缺陷，应该报告给开发者！

慢请求（ MDS 端）¶
通过管理套接字，你可以罗列当前正在运行的操作：

ceph daemon mds.<name> dump_ops_in_flight
在 MDS 主机上执行。找出卡住的命令、并调查卡住的原因。通常最后一个“事件”（ event ）尝试过收集锁、或者把这个操作发往 MDS 日志。如果它是在等待 OSD ，修正即可；如果操作都卡在了某个索引节点上，原因可能是一个客户端一直占着能力，别人就没法拿到，也可能是这个客户端想刷回脏数据，还可能是你遇到了 CephFS 分布式文件锁的代码（文件能力子系统、 capabilities 、 caps ）缺陷。

如果起因是能力代码的缺陷，重启 MDS 也许能解决此问题。

如果 MDS 上没发现慢请求，而且也没报告客户端行为异常，那问题就可能在客户端上、或者它的请求还没到 MDS 上。

ceph-fuse 的调试¶
ceph-fuse 也支持 dump_ops_in_flight 命令，可以查看是否卡住、卡在哪里了。

调试输出¶
要想看到 ceph-fuse 的更多调试信息，试试在前台运行，让日志输出到控制台（ -d ）、打开客户端调试（ --debug-client=20 ）、打印发送过的所有消息（ --debug-ms=1 ）。

如果你怀疑是监视器的问题，也可以打开监视器调试开关（ --debug-monc=20 ）。

内核挂载的调试¶
慢请求¶
遗憾的是内核客户端不支持管理套接字，可是如果你的内核启用了（如果限制过） debugfs ，那么它就有相似的接口了。 sys/kernel/debug/ceph/ 路径下有一个文件夹（其名字形如 28f7427e-5558-4ffd-ae1a-51ec3042759a.client25386880 ），而且其内包含很多文件，用 cat 命令查看它们的内容时会看到有趣的输出。这些文件描述如下，最有助于调试慢请求问题的文件可能是 mdsc 和 osdc 。

bdi: 关于 Ceph 系统的 BDI 信息（脏块、已写入的等等）

caps: 文件的 caps 数据结构计数，包括内存中的和用过的

client_options: 倒出挂载 CephFS 时所用的选项

dentry_lru: 倒出当前内存中的 CephFS dentry

mdsc: 倒出当前发给 MDS 的请求

mdsmap: 倒出当前的 MDSMap 时间结和所有 MDS

mds_sessions: 倒出当前与 MDS 建立的会话

monc: 倒出当前从监视器获取的各种映射图，以及其它“订阅”信息

monmap: 倒出当前的监视器图和所有监视器

osdc: 倒出当前发往 OSD 的操作（即文件数据的 IO ）

osdmap: 倒出当前的 OSDMap 时间结、存储池、所有 OSD

如果没有卡住的请求，却有毫无进展的文件 IO ，问题也许是……

断线后又重新挂载的文件系统¶
因为 CephFS 有个“一致性缓存”，如果你的网络连接中断时间较长，客户端就会被系统强制断开，此时，内核客户端仍然傻站着（ in a bind ）：它不能安全地写回脏数据，另外很多应用程序在 close() 时不能正确处理 IO 错误。这个时候，内核客户端会重新挂载这个文件系统，但是先前的文件系统 IO 也许能完成、也许不能，这些情况下，你也许得重启客户端系统。

如果 dmesg 或者 kern.log 里出现了类似消息，说明你遇到的就是这种情况：

Jul 20 08:14:38 teuthology kernel: [3677601.123718] ceph: mds0 closed our session
Jul 20 08:14:38 teuthology kernel: [3677601.128019] ceph: mds0 reconnect start
Jul 20 08:14:39 teuthology kernel: [3677602.093378] ceph: mds0 reconnect denied
Jul 20 08:14:39 teuthology kernel: [3677602.098525] ceph: dropping dirty+flushing Fw state for ffff8802dc150518 1099935956631
Jul 20 08:14:39 teuthology kernel: [3677602.107145] ceph: dropping dirty+flushing Fw state for ffff8801008e8518 1099935946707
Jul 20 08:14:39 teuthology kernel: [3677602.196747] libceph: mds0 172.21.5.114:6812 socket closed (con state OPEN)
Jul 20 08:14:40 teuthology kernel: [3677603.126214] libceph: mds0 172.21.5.114:6812 connection reset
Jul 20 08:14:40 teuthology kernel: [3677603.132176] libceph: reset on mds0
这是正在改善的领域，内核将很快能够可靠地向正在进行的 IO 发送错误代码，即便你的应用程序不能良好地应对这些情况。长远来看，在不违背 POSIX 语义的情况下，我们希望可以重连和回收数据（通常是其它客户端尚未访问、或修改的数据）。

挂载问题¶
Mount 5 Error¶
mount 5 错误通常是 MDS 服务器滞后或崩溃导致的。要确保至少有一个 MDS 是启动且运行的，集群也要处于 active+healthy 状态。

Mount 12 Error¶
mount 12 错误显示 cannot allocate memory ，常见于 Ceph 客户端和 Ceph 存储集群版本不匹配。用以下命令检查版本：

ceph -v
如果 Ceph 客户端版本落后于集群，试着升级它：

sudo apt-get update && sudo apt-get install ceph-common
你也许得卸载、清理和删除 ceph-common ，然后再重新安装，以确保安装的是最新版。

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

cephfs文件系统中客户端的驱逐自动，手动等

浏览过的版块