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

admin

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

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

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

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

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

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

• 在一个活跃的 MDS 守护进程上，如果一个客户端在限定的时间 session_autoclose （一个文件系统变量）秒数（默认 300 秒）内没有与 MDS 通讯，它就会被自动驱逐。
  
• 在一个活跃的 MDS 守护进程上，如果一个客户端在限定的时间 mds_cap_revoke_eviction_timeout （配置变量）秒数（默认 300 秒）内没有回应 cap 撤销消息。默认已禁用。
  ; o" F) L( u) U0 R0 F& ~( K
• 在 MDS 启动（包括故障恢复）期间，它要途径一个名为 reconnect 的状态，在这个状态下，它会等待所有客户端连接到这个新 MDS 守护进程。如果有客户端在限期（ mds_reconnect_timeout ，默认 45 秒 ）内未能连上，它们就会被驱逐。
  
  % @, g' C1 C% ^

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

手动驱逐客户端¶有时候，管理员可能得手动驱逐某个客户端。比如说，一个客户端已死，管理员不想等它的会话超时；或者有个客户端行为异常，管理员又无法登录客户端节点卸载它。
一般要先检查下客户端列表：
. e2 P5 l. s# r5 c, [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 、或者其它属性来标识它：
6 e. e5 |! U# s1 [% [- z4 C# 这些都可以ceph tell mds.0 client evict id=4305ceph tell mds.0 client evict client_metadata.=4305
2 t1 t8 P5 I6 ]. p
1 @7 d$ {/ |' x7 J3 |# Z0 o
高级话题：从黑名单踢出客户端¶通常，进了黑名单的客户端就不能再重新连接服务器了：它必须被卸载、然后再重新挂载。
- l2 ?1 f& C. g: m8 K6 W% r" [  ~然而，在某些情况下，还是得允许被驱逐后、又想重连的客户端。
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 ，以此为客户端重连提速。
6 o& `. L- z2 N1 i
4 o+ a3 T- A+ s& q高级话题：配置黑名单功能¶如果由于客户端主机慢或者网络不可靠，频繁遇到客户端驱逐，这些底层问题还解决不了，你可以让 MDS 别那么严格。
2 g. T6 s. \5 @$ M0 i  b4 g7 l% _对于响应缓慢的客户端，可以简单地丢弃它们的 MDS 会话，却允许它们重新开启会话并且允许它们继续与 OSD 通讯。要打开这种模式，可以在 MDS 节点上把 mds_session_blacklist_on_timeout 设置为 false 。
5 s. G  z3 N. Q. p) o对于手动驱逐时的类似情形，可以把 mds_session_blacklist_on_evict 设置为 false 。
2 c9 p$ q4 {2 u  ^* Z  u. J4 i注意，如果禁用了黑名单功能，那么驱逐客户端只会在收到了命令的 MDS 上生效。在一个多活 MDS 系统上，你得向所有活跃的 MDS 守护进程发送驱逐命令。黑名单功能启用时（默认如此），只要把驱逐命令发给一个 MDS 就足够了，因为黑名单会自动扩散到其余守护进程。

: \4 l$ i) @) g. j' P- _% Y. A背景： 黑名单和 OSD 元图屏蔽¶一个客户端被加入黑名单后，有必要确保其它客户端和 MDS 守护进程能收到最新的 OSDMap （新增了这条黑名单的），以免有人再访问那些进了黑名单的客户端访问过的数据对象。
2 z9 X8 Z, s) i" O  G  S+ s+ `5 @3 _这是通过名为 “osdmap epoch barrier” 的内部机制保证的。
此屏蔽的目的是为了确保当我们分配出这些能力后，别的客户端就有可能触碰同样的 RADOS 对象，接受分配能力的客户端们必须有足够新的 OSD 图，这样它们才不会与取消的操作（来自 ENOSPC ）或进了黑名单的客户端（来自驱逐过程）竞争。
更具体些，我们设置元图屏蔽的情形有：

• 客户端驱逐（此客户端被加入黑名单了、且其它客户端必须等到有加黑之后的元图出现才能触碰同一批对象）；
  0 ]9 K( D5 F* U, B: n' `
• 客户端正在处理 OSD 图的完整标识（此客户端可能会在快完整的元图中取消一些 OSD 操作，这样其它客户端都必须等着，直到元图完整或周期达到才能触碰同样的对象）；
  
• MDS 启动，因为我们不会永久存储屏蔽图元，所以必须假设重启后总是需要最新的 OSD 图。
  ; J8 l+ {  `5 l6 C# H; ?1 J. f
  

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

• 它会复杂得多；
  8 f' r' v8 V% l+ O$ u1 W3 J2 A
• 每索引节点需额外多占 4 字节的内存；
  ( \1 d) [# z/ U# w  ?
• 无论如何它都不会比大家一直都拥有最新的 OSD 图更有效。而且，大多数情况下，大家都能轻松地越过这个屏障而不是等着它。
  
• 我们仅在极少数情形下使用这种屏蔽，所以每索引节点这样细粒度的实现带来的好处也很少见。
  
  4 p2 M, \! ]; @8 [' d* D  O" ~5 M" ^

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

" b  W! _" j7 Z3 \% R9 j2 A( O

admin

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

% _* ]$ Z3 a9 C! u/ L3 s. z文件系统对 full 标记还有些特殊处理，下文详述。

Hammer 及更高版¶
) i- ~  u( ~: q* I! h# D从 hammer 发布开始，以下行为会导致占满的文件系统返回 ENOSPC 错误：
- K2 ~* v; j+ V" w
客户端写入数据
) b$ R* t7 b# H9 h
删除和裁剪以外的其它元数据操作
% X9 J& {: r8 m: M
; v- L/ B5 M. ~& c因为只有在数据刷回到硬盘（有时是 write 返回 0 之后）才可能遇到占满的情况，所以应用程序调用 fsync 或 fclose （或等价操作）进行文件处理时才可能遇到 ENOSPC 错误。
' c+ @* r% }8 l# N0 s( w$ `2 v* |
' L1 q* @, O/ k2 L: ]! W调用 fsync 能可靠地反映数据是否写入了硬盘，并且在没写入时返回错误。 fclose 只有在缓冲的数据从上次写入以来被偶尔刷回过才会返回错误［译者：原文可能有误］—— fclose 成功并不能保证数据写入了硬盘，而且在空间占满时， fclose 之后如果没地方存储缓冲的数据，它们就可能被丢弃。
& E/ E. b! I2 I. E
Warning
0 }4 y- o8 U$ o+ H
! X7 {5 y- ~* q; o# ^) ]( y如果某一应用程序在占满的文件系统上行为异常，有必要检查下它调用了 fsync() 来确保数据已写入硬盘，然后再继续。
4 i3 U9 ~5 o, A; {) p
如果客户端运行时已经看到了 OSD full 标记，写数据操作可能被取消。各个客户端取消操作并释放文件能力时会更新 osd_epoch_barrier ，以确保这些取消的操作不会妨碍 MDS 或其它客户端对这些数据对象的访问。要了解元图屏蔽机制，请参考 背景： 黑名单和 OSD 元图屏蔽 。

) ^5 |* p" B3 r8 P老版本（ hammer 之前）的行为¶
; E# @; e  }+ {7 @在 hammer 之前的 Ceph 版本中， MDS 会忽略 RADOS 集群的占满状态，而且客户端的任意数据写入都会卡死，直到集群脱离占满状态。
# |( m- t1 M/ w% R6 t/ V2 L5 t; H
# N# G7 b6 J# r0 T! b4 D; B出现这种行为时有两种危险情形要注意：
# \* S; a- V5 S7 n: p
如果一客户端到一个文件的写入未完成，那么它不可能把文件释放给 MDS 让它删除，这样就很难清理占满的文件系统。

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

admin

故障排除¶
& ?* B- R2 b0 S- l: `( J慢或卡住的操作¶
3 U' ~$ q# M8 b: x. j, f如果遇到了明显的卡顿操作，首先要定位问题源头：是客户端、 MDS 、抑或是连接二者的网络。从存在卡顿操作的地方下手（参考下面的 慢请求（ MDS 端） ），进而缩小范围。

* ~% T6 L+ ]9 j1 xRADOS 健康状况¶
( {2 w( B- e/ _) V) ]如果 CephFS 的元数据或者数据存储池的某一部分不可用、且 CephFS 不响应，很有可能是 RADOS 本身有问题，应该先解决这样的问题（ 故障排除 ）。
/ ^& z0 u0 }( H+ k# ^. ?
. y  U/ z  M& v- y& ~5 tMDS 问题¶
如果某个操作卡在了 MDS 内部，类似 “slow requests are blocked” 的消息最终会出现在 ceph health 里，也可能指出是客户端的问题，如 “failing to respond” 或其它形式的异常行为。如果 MDS 认定某些客户端的行为异常，你应该弄明白起因。常见起因有：
. G: L8 g3 W" c$ T& K5 g
系统过载（如果你还有空闲内存，增大 mds cache size 配置试试，默认才 100000 。活跃文件比较多，超过 MDS 缓存容量是此问题的首要起因！）

客户端比较老（行为异常），或者
1 @8 b4 _( k) _8 R3 F' k8 d3 Y) Z
底层的 RADOS 问题。

/ U9 L' [  b2 t6 j4 C除此之外，你也许遇到了新的软件缺陷，应该报告给开发者！

5 `6 k: c4 ^7 U* K慢请求（ MDS 端）¶
, K; N# y% j: i! a9 `4 a, E通过管理套接字，你可以罗列当前正在运行的操作：
+ L5 Q! V$ C; s0 u
; {7 _2 ^1 z" |) `! Jceph daemon mds.<name> dump_ops_in_flight
5 N& i; ~  g# i+ k' L在 MDS 主机上执行。找出卡住的命令、并调查卡住的原因。通常最后一个“事件”（ event ）尝试过收集锁、或者把这个操作发往 MDS 日志。如果它是在等待 OSD ，修正即可；如果操作都卡在了某个索引节点上，原因可能是一个客户端一直占着能力，别人就没法拿到，也可能是这个客户端想刷回脏数据，还可能是你遇到了 CephFS 分布式文件锁的代码（文件能力子系统、 capabilities 、 caps ）缺陷。

如果起因是能力代码的缺陷，重启 MDS 也许能解决此问题。
& p5 B8 Z& S' Z* E( q4 p) L
如果 MDS 上没发现慢请求，而且也没报告客户端行为异常，那问题就可能在客户端上、或者它的请求还没到 MDS 上。

ceph-fuse 的调试¶
ceph-fuse 也支持 dump_ops_in_flight 命令，可以查看是否卡住、卡在哪里了。
9 {( w2 y/ Y0 [+ s
调试输出¶
! T( Z; [5 m: t0 l- L2 D  a要想看到 ceph-fuse 的更多调试信息，试试在前台运行，让日志输出到控制台（ -d ）、打开客户端调试（ --debug-client=20 ）、打印发送过的所有消息（ --debug-ms=1 ）。

9 d& u( A) Q: J( R' R如果你怀疑是监视器的问题，也可以打开监视器调试开关（ --debug-monc=20 ）。

* _! D6 n9 S5 U. K- R内核挂载的调试¶
慢请求¶
遗憾的是内核客户端不支持管理套接字，可是如果你的内核启用了（如果限制过） debugfs ，那么它就有相似的接口了。 sys/kernel/debug/ceph/ 路径下有一个文件夹（其名字形如 28f7427e-5558-4ffd-ae1a-51ec3042759a.client25386880 ），而且其内包含很多文件，用 cat 命令查看它们的内容时会看到有趣的输出。这些文件描述如下，最有助于调试慢请求问题的文件可能是 mdsc 和 osdc 。
' H% L: P9 m4 w: I, q' w5 R
* {7 F1 C  [* b4 Mbdi: 关于 Ceph 系统的 BDI 信息（脏块、已写入的等等）
9 y  m) o5 Y; Y3 N8 ]% k6 N
# H$ x% o0 q  P! o9 B1 S) k7 _2 j: Dcaps: 文件的 caps 数据结构计数，包括内存中的和用过的

client_options: 倒出挂载 CephFS 时所用的选项
) @" @# g# v. {" E1 w
" N2 i- e% s/ m8 B- x/ {dentry_lru: 倒出当前内存中的 CephFS dentry
' G8 ?' v1 w2 D+ ^
! R# K5 T8 p6 \+ D" k( Umdsc: 倒出当前发给 MDS 的请求

8 N) U2 ?7 N6 W; Q0 X& ~2 F( l$ dmdsmap: 倒出当前的 MDSMap 时间结和所有 MDS

' \( M9 U4 u8 ^( P7 y0 b. h6 ^mds_sessions: 倒出当前与 MDS 建立的会话

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

& B3 h0 @& O0 g8 c/ emonmap: 倒出当前的监视器图和所有监视器

osdc: 倒出当前发往 OSD 的操作（即文件数据的 IO ）
$ J$ o2 w+ l2 c# R
osdmap: 倒出当前的 OSDMap 时间结、存储池、所有 OSD
  L6 @" W" w3 s: R5 @
, y5 R! R& {+ L) H" B" z如果没有卡住的请求，却有毫无进展的文件 IO ，问题也许是……
9 M1 u, Y" x- b) d, a: v
, O) J& D( c$ J" m- t# o/ |断线后又重新挂载的文件系统¶
( \( o) F9 N4 s8 b因为 CephFS 有个“一致性缓存”，如果你的网络连接中断时间较长，客户端就会被系统强制断开，此时，内核客户端仍然傻站着（ in a bind ）：它不能安全地写回脏数据，另外很多应用程序在 close() 时不能正确处理 IO 错误。这个时候，内核客户端会重新挂载这个文件系统，但是先前的文件系统 IO 也许能完成、也许不能，这些情况下，你也许得重启客户端系统。
# {( A( e1 }$ M& f2 K
如果 dmesg 或者 kern.log 里出现了类似消息，说明你遇到的就是这种情况：
2 d, w" s2 o, w- J
Jul 20 08:14:38 teuthology kernel: [3677601.123718] ceph: mds0 closed our session
6 i3 ]# P8 }0 e' g2 Y: U" rJul 20 08:14:38 teuthology kernel: [3677601.128019] ceph: mds0 reconnect start
  e& `. s/ \4 T  m9 T! M4 o- LJul 20 08:14:39 teuthology kernel: [3677602.093378] ceph: mds0 reconnect denied
3 ?' ^- \6 B3 _) y3 SJul 20 08:14:39 teuthology kernel: [3677602.098525] ceph:  dropping dirty+flushing Fw state for ffff8802dc150518 1099935956631
, e8 i7 \( l6 H- s: zJul 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
" J7 h0 U5 N9 f& G. Z) s- @8 l这是正在改善的领域，内核将很快能够可靠地向正在进行的 IO 发送错误代码，即便你的应用程序不能良好地应对这些情况。长远来看，在不违背 POSIX 语义的情况下，我们希望可以重连和回收数据（通常是其它客户端尚未访问、或修改的数据）。

6 E0 S. F2 ]# d( [挂载问题¶
Mount 5 Error¶
3 P+ s2 P1 @, P# ^9 P# Z' Imount 5 错误通常是 MDS 服务器滞后或崩溃导致的。要确保至少有一个 MDS 是启动且运行的，集群也要处于 active+healthy 状态。
/ w4 u" l7 T7 W3 X+ l0 O+ W
% u5 j2 s+ C: X+ w2 mMount 12 Error¶
, D+ J* H( }4 a* K; h- G' }! Pmount 12 错误显示 cannot allocate memory ，常见于 Ceph 客户端和 Ceph 存储集群版本不匹配。用以下命令检查版本：
8 H: K( s! G$ |4 g
2 G9 \& A) m0 F1 w! ^ceph -v
如果 Ceph 客户端版本落后于集群，试着升级它：
& L) r3 E( s( c
  L( q0 ]: m6 ?" Csudo apt-get update && sudo apt-get install ceph-common
你也许得卸载、清理和删除 ceph-common ，然后再重新安装，以确保安装的是最新版。