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

admin

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

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

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

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

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

自动驱逐客户端¶在三种情况下，客户端会被自动驱逐：
3 _  P0 h' v* l& r/ h/ j

• 在一个活跃的 MDS 守护进程上，如果一个客户端在限定的时间 session_autoclose （一个文件系统变量）秒数（默认 300 秒）内没有与 MDS 通讯，它就会被自动驱逐。
  
• 在一个活跃的 MDS 守护进程上，如果一个客户端在限定的时间 mds_cap_revoke_eviction_timeout （配置变量）秒数（默认 300 秒）内没有回应 cap 撤销消息。默认已禁用。
  
• 在 MDS 启动（包括故障恢复）期间，它要途径一个名为 reconnect 的状态，在这个状态下，它会等待所有客户端连接到这个新 MDS 守护进程。如果有客户端在限期（ mds_reconnect_timeout ，默认 45 秒 ）内未能连上，它们就会被驱逐。
  ; e/ M/ O9 S: x: n
  - n0 |# f# i- t$ P1 G& |

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

0 U( I' `# N7 u' H4 L+ H7 B手动驱逐客户端¶有时候，管理员可能得手动驱逐某个客户端。比如说，一个客户端已死，管理员不想等它的会话超时；或者有个客户端行为异常，管理员又无法登录客户端节点卸载它。
一般要先检查下客户端列表：
: _$ p) R# E  Bceph 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 、或者其它属性来标识它：
; z1 T# o0 T3 W* G# 这些都可以ceph tell mds.0 client evict id=4305ceph tell mds.0 client evict client_metadata.=4305

7 U7 W" B  M6 {' f! P
高级话题：从黑名单踢出客户端¶通常，进了黑名单的客户端就不能再重新连接服务器了：它必须被卸载、然后再重新挂载。
然而，在某些情况下，还是得允许被驱逐后、又想重连的客户端。
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

% K8 [9 t; R* J' M假如被拉黑的客户端对缓冲 IO 做了操作，而其它客户端访问了这些文件，这样做就可能会破坏数据完整性。而且也不能确定客户端功能会完全恢复——要想挽回一个完全健康的被驱逐客户端，最好的方法是把它卸载掉，然后再干净地挂载。
; G/ N8 d- F1 ?$ e. N如果你想这样重连客户端，可以在 FUSE 客户端上设置 client_reconnect_stale 为 true ，以此为客户端重连提速。

高级话题：配置黑名单功能¶如果由于客户端主机慢或者网络不可靠，频繁遇到客户端驱逐，这些底层问题还解决不了，你可以让 MDS 别那么严格。
& O( `- B+ @. o9 S5 a+ P对于响应缓慢的客户端，可以简单地丢弃它们的 MDS 会话，却允许它们重新开启会话并且允许它们继续与 OSD 通讯。要打开这种模式，可以在 MDS 节点上把 mds_session_blacklist_on_timeout 设置为 false 。
对于手动驱逐时的类似情形，可以把 mds_session_blacklist_on_evict 设置为 false 。
5 _& n# }$ _1 b! c# v9 f注意，如果禁用了黑名单功能，那么驱逐客户端只会在收到了命令的 MDS 上生效。在一个多活 MDS 系统上，你得向所有活跃的 MDS 守护进程发送驱逐命令。黑名单功能启用时（默认如此），只要把驱逐命令发给一个 MDS 就足够了，因为黑名单会自动扩散到其余守护进程。

背景： 黑名单和 OSD 元图屏蔽¶一个客户端被加入黑名单后，有必要确保其它客户端和 MDS 守护进程能收到最新的 OSDMap （新增了这条黑名单的），以免有人再访问那些进了黑名单的客户端访问过的数据对象。
% p3 v/ J' Q- i这是通过名为 “osdmap epoch barrier” 的内部机制保证的。
此屏蔽的目的是为了确保当我们分配出这些能力后，别的客户端就有可能触碰同样的 RADOS 对象，接受分配能力的客户端们必须有足够新的 OSD 图，这样它们才不会与取消的操作（来自 ENOSPC ）或进了黑名单的客户端（来自驱逐过程）竞争。
& u5 l$ Q2 X! E( ]; {更具体些，我们设置元图屏蔽的情形有：

• 客户端驱逐（此客户端被加入黑名单了、且其它客户端必须等到有加黑之后的元图出现才能触碰同一批对象）；
  6 \1 W; }3 `, z4 m- h/ \- k  c' p
• 客户端正在处理 OSD 图的完整标识（此客户端可能会在快完整的元图中取消一些 OSD 操作，这样其它客户端都必须等着，直到元图完整或周期达到才能触碰同样的对象）；
  ( Z( l/ U* V/ |  k
• MDS 启动，因为我们不会永久存储屏蔽图元，所以必须假设重启后总是需要最新的 OSD 图。
  
  

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

• 它会复杂得多；
  5 q5 z: |$ u6 B
• 每索引节点需额外多占 4 字节的内存；
  
• 无论如何它都不会比大家一直都拥有最新的 OSD 图更有效。而且，大多数情况下，大家都能轻松地越过这个屏障而不是等着它。
  
• 我们仅在极少数情形下使用这种屏蔽，所以每索引节点这样细粒度的实现带来的好处也很少见。
  . j1 g. @7 x; _) c) L' U
  

元图屏蔽随其它能力消息一起传递，并且可指示消息接收器在看到这个 OSD 元图前、别再向那些 OSD 发送 RADOS 操作。主要是面向客户端（它们直接向文件写入数据）的，也适用于 MDS ，因为像文件尺寸探测和文件删除这样的操作都是直接在 MDS 上进行的。
9 y  `" s! C2 M4 j3 h9 k
/ l. D' x: I$ D1 Y

admin

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

0 ]- d! X+ z+ C& ?7 z% m$ p( m文件系统对 full 标记还有些特殊处理，下文详述。
7 k1 [; r  |* C
. w- J7 x- y1 F# q* t2 N; x9 hHammer 及更高版¶
, [6 W4 F' s# {6 U从 hammer 发布开始，以下行为会导致占满的文件系统返回 ENOSPC 错误：

( T; q2 O/ E! [3 y* N1 j  b客户端写入数据

, n3 c8 [- y2 o) c+ @8 ?删除和裁剪以外的其它元数据操作

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

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

Warning
& A4 r) p( I; Y- q' y" v
0 L0 ?. U! X3 N5 E# [7 a如果某一应用程序在占满的文件系统上行为异常，有必要检查下它调用了 fsync() 来确保数据已写入硬盘，然后再继续。
/ F4 h. H& p- L
7 x: p8 x, K9 X( F' X' ^! ?4 Y如果客户端运行时已经看到了 OSD full 标记，写数据操作可能被取消。各个客户端取消操作并释放文件能力时会更新 osd_epoch_barrier ，以确保这些取消的操作不会妨碍 MDS 或其它客户端对这些数据对象的访问。要了解元图屏蔽机制，请参考 背景： 黑名单和 OSD 元图屏蔽 。
" A- w3 o4 v7 |5 l) B& ^* j
3 X" U' _. m7 [老版本（ hammer 之前）的行为¶
在 hammer 之前的 Ceph 版本中， MDS 会忽略 RADOS 集群的占满状态，而且客户端的任意数据写入都会卡死，直到集群脱离占满状态。
+ d  ]+ U9 F+ M, ~% B# d
出现这种行为时有两种危险情形要注意：

& k3 V0 u% l9 S# w如果一客户端到一个文件的写入未完成，那么它不可能把文件释放给 MDS 让它删除，这样就很难清理占满的文件系统。
' I  e- l/ f# U6 }) i
如果客户端持续地创建大量空文件，来自 MDS 的元数据写入操作终将会耗尽 OSD 空间，这样就再也不能执行删除动作了。

admin

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

* }  i; Y4 p, J" tRADOS 健康状况¶
如果 CephFS 的元数据或者数据存储池的某一部分不可用、且 CephFS 不响应，很有可能是 RADOS 本身有问题，应该先解决这样的问题（ 故障排除 ）。
  F& r& c. d  S
MDS 问题¶
1 n  E- m2 l$ T如果某个操作卡在了 MDS 内部，类似 “slow requests are blocked” 的消息最终会出现在 ceph health 里，也可能指出是客户端的问题，如 “failing to respond” 或其它形式的异常行为。如果 MDS 认定某些客户端的行为异常，你应该弄明白起因。常见起因有：
/ }8 b8 _7 m: D; L- ~; W" c
' w# ?  i6 j2 s7 _系统过载（如果你还有空闲内存，增大 mds cache size 配置试试，默认才 100000 。活跃文件比较多，超过 MDS 缓存容量是此问题的首要起因！）

客户端比较老（行为异常），或者
) l4 {* Y$ z  ^0 I( w
5 ^9 R. e1 t$ a2 V底层的 RADOS 问题。
, Q3 {- E: I8 w; t
除此之外，你也许遇到了新的软件缺陷，应该报告给开发者！

慢请求（ MDS 端）¶
; ~) A0 T+ B* h* j4 O通过管理套接字，你可以罗列当前正在运行的操作：

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

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

如果 MDS 上没发现慢请求，而且也没报告客户端行为异常，那问题就可能在客户端上、或者它的请求还没到 MDS 上。
9 e5 L1 r+ L. v+ n$ d
ceph-fuse 的调试¶
, s7 A5 h2 G, M0 j. y1 mceph-fuse 也支持 dump_ops_in_flight 命令，可以查看是否卡住、卡在哪里了。
& K; m& R! h- C* b5 k. h! u: f
调试输出¶
要想看到 ceph-fuse 的更多调试信息，试试在前台运行，让日志输出到控制台（ -d ）、打开客户端调试（ --debug-client=20 ）、打印发送过的所有消息（ --debug-ms=1 ）。

5 k3 _$ G5 B1 W/ H如果你怀疑是监视器的问题，也可以打开监视器调试开关（ --debug-monc=20 ）。
, q. f0 f7 G1 M& U! G3 c. q1 R; [
* A# ]- h- \$ W) r内核挂载的调试¶
- U( p- x5 D: ~* n7 O- S慢请求¶
5 g" o& O4 L& t+ Q遗憾的是内核客户端不支持管理套接字，可是如果你的内核启用了（如果限制过） debugfs ，那么它就有相似的接口了。 sys/kernel/debug/ceph/ 路径下有一个文件夹（其名字形如 28f7427e-5558-4ffd-ae1a-51ec3042759a.client25386880 ），而且其内包含很多文件，用 cat 命令查看它们的内容时会看到有趣的输出。这些文件描述如下，最有助于调试慢请求问题的文件可能是 mdsc 和 osdc 。

bdi: 关于 Ceph 系统的 BDI 信息（脏块、已写入的等等）
. V2 W. A3 I) T5 R4 L6 }
caps: 文件的 caps 数据结构计数，包括内存中的和用过的

7 ?: ?3 J) K& U/ x9 P4 xclient_options: 倒出挂载 CephFS 时所用的选项

dentry_lru: 倒出当前内存中的 CephFS dentry
4 J* O$ i3 @4 L+ ?: \" K9 p% P/ _
mdsc: 倒出当前发给 MDS 的请求
3 @7 _: ^6 a$ `  q) D' O1 Q
2 w, E  b" V6 r. smdsmap: 倒出当前的 MDSMap 时间结和所有 MDS

mds_sessions: 倒出当前与 MDS 建立的会话
5 ?/ e2 w# ^" t
monc: 倒出当前从监视器获取的各种映射图，以及其它“订阅”信息

) g4 L1 F+ P; e) e/ Mmonmap: 倒出当前的监视器图和所有监视器
. E' L4 r2 d  t. f7 j2 i% a
4 P, c" E  ^+ y& }+ y( d5 e: oosdc: 倒出当前发往 OSD 的操作（即文件数据的 IO ）

) p" l$ f8 t' J4 g3 X* ?* R) v4 K! Dosdmap: 倒出当前的 OSDMap 时间结、存储池、所有 OSD
. E" c( w! V) y( X( I  n! m
如果没有卡住的请求，却有毫无进展的文件 IO ，问题也许是……

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

如果 dmesg 或者 kern.log 里出现了类似消息，说明你遇到的就是这种情况：
2 H( i; X7 G- {3 @3 t! o
; s% S4 f: P; h( qJul 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
9 x  Y: G  V+ j: y% N, wJul 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
; p+ q* z5 I0 u1 S8 t9 \: sJul 20 08:14:40 teuthology kernel: [3677603.132176] libceph: reset on mds0
这是正在改善的领域，内核将很快能够可靠地向正在进行的 IO 发送错误代码，即便你的应用程序不能良好地应对这些情况。长远来看，在不违背 POSIX 语义的情况下，我们希望可以重连和回收数据（通常是其它客户端尚未访问、或修改的数据）。
% p: J! q$ ^+ k' r
6 v' s/ M4 @0 @3 V3 ?挂载问题¶
Mount 5 Error¶
mount 5 错误通常是 MDS 服务器滞后或崩溃导致的。要确保至少有一个 MDS 是启动且运行的，集群也要处于 active+healthy 状态。

- V2 f4 {8 x5 z9 n4 O3 y7 BMount 12 Error¶
: M& r  P2 n9 A, j+ Smount 12 错误显示 cannot allocate memory ，常见于 Ceph 客户端和 Ceph 存储集群版本不匹配。用以下命令检查版本：
$ u( |" ?  r3 G7 G$ s& |
) c4 r) a+ I3 V8 d# o3 Iceph -v
如果 Ceph 客户端版本落后于集群，试着升级它：

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