cephfs 提示MDS_SLOW_METADATA_IO: 1 MDSs report slow metadata IOs ceph出现读写慢

admin

[root@8-5 ~]# ceph health detail
8 u0 r$ F0 R* J6 mHEALTH_WARN 1 MDSs report slow metadata IOs; 1 MDSs report slow requests
* p7 a7 E) H7 G( R, o) |[WRN] MDS_SLOW_METADATA_IO: 1 MDSs report slow metadata IOs
    mds.cephfs.gm268-2.xdsdoz(mds.0): 100+ slow metadata IOs are blocked > 30 secs, oldest blocked for 2718 secs
/ S+ q6 V8 G3 Z, _[WRN] MDS_SLOW_REQUEST: 1 MDSs report slow requests
    mds.cephfs.gm268-2.xdsdoz(mds.0): 73 slow requests are blocked > 30 secs
. F3 ~; ^, Q2 G- X! r
2 L4 V8 k. d& o. D6 t
3 _! B7 m3 N0 {: _出现这种提示会导致集群对请求没有反应，解决办法就是重启所有的ceph节点即可：
4 `0 E% S" a# O% Q, x1 N5 J  gsystemctl restart ceph.target或者重启服务器也可解决问题，响应慢可以使用重启的方式来重新发起集群数据均衡。

观察结果
$ p$ W8 U& r) Y; F  c- [7 p& ^8 @: U
( s  l) a' W5 B6 E/ f
+ n1 |. r7 N) V; V$ n  F

# {& S* r  j4 A2 x1. Slow OSD heartbeats

• # ceph -s
• health: HEALTH_WARN
•        Slow OSD heartbeats on back (longest 6181.010ms)
•        Slow OSD heartbeats on front (longest 5953.232ms)
  6 w" |- P" X3 {( r

OSDs之间会相互测试（ping）访问速度，若两个OSDs之间的连接延迟高于1s，则表示OSDs之间的延迟太高，不利于CEPH集群的数据存储和访问。两个OSDs之间可以通过内网（存储服务器之间 / back）检测其延迟，也可以通过外网（存储服务器到使用服务器 / front）检测其延迟。若延迟过高，会将相应的OSDs down掉，进而可能导致CEPH数据丢失。

一般情况下OSDs之间延迟高的原因是因为网络原因导致的。可能是某台存储服务器重启网络导致，或网线出问题导致。前者的时间会逐渐变小，最后恢复正常，后者则问题一直存在。通过查看详细的OSDs延迟信息查找延迟较高的主机，再进行解决。

• # ceph health detail
• [WRN OSD_SLOW_PING_TIME_BACK: Slow OSD heartbeats on back (longest 11846.602ms)
•     Slow OSD heartbeats on back from osd.12 [] to osd.25 [] 11846.602 msec
•     Slow OSD heartbeats on back from osd.8 [] to osd.17 [] 3617.281 msec
•     Slow OSD heartbeats on back from osd.16 [] to osd.27 [] 2784.517 msec
•     Slow OSD heartbeats on back from osd.21 [] to osd.17 [] 1678.064 msec
•     Slow OSD heartbeats on back from osd.11 [] to osd.15 [] 1675.884 msec
•     Slow OSD heartbeats on back from osd.20 [] to osd.13 [] 1073.790 msec
• [WRN OSD_SLOW_PING_TIME_FRONT: Slow OSD heartbeats on front (longest 11427.677ms)
•     Slow OSD heartbeats on front from osd.12 [] to osd.25 [] 11427.677 msec
•     Slow OSD heartbeats on front from osd.8 [] to osd.17 [] 3787.868 msec
•     Slow OSD heartbeats on front from osd.16 [] to osd.27 [] 3465.298 msec
•     Slow OSD heartbeats on front from osd.11 [] to osd.15 [] 1469.591 msec
•     Slow OSD heartbeats on front from osd.21 [] to osd.17 [] 1341.135 msec
•     Slow OSD heartbeats on front from osd.20 [] to osd.13 [] 1224.235 msec
•     Slow OSD heartbeats on front from osd.5 [] to osd.16 [] 1101.175 msec
• 通过以上信息查看，可以发现有一台主机和其它主机的OSDs延迟都比较高，将该主机的光纤网线拔下擦拭干净并重新插上得以解决。
  

2. slow ops

• # ceph -s
•      21 slow ops, oldest one blocked for 29972 sec, mon.ceph1 has slow ops
  

先保证所有存储服务器上的时间同步一致，再重启相应主机上的moniter服务解决。

3. pgs not deep-scrubbed in time

• # ceph -s
•     47 pgs not deep-scrubbed in time
  : F# ^) T$ q4 p. s/ ]1 {

应该是OSDs掉线后，CEPH自动进行数据恢复。再将相应的OSDs重新加入后，则需要将恢复的数据再擦除掉。于是提示相应的警告信息，正在进行删除相关的操作，且其pgs的数量会不断变少。等待一段时间后，则恢复正常，此时ceph文件系统性能很差。

4. MDS cache is too large

• ceph config set mds mds_cache_memory_limit 10GB
• ceph config dump
  

当MDS使用的缓存过高，比设定的阈值高很多时，则有此警告信息。使用如上命令设置更高的MDS缓存阈值，即可消除次警告信息，但会消耗更多的内存。使用config dump命令可以查看各项参数阈值信息。

此外，可能增大了mds_cache_memory_limit参数后，过了一段时间后仍然提示该警告，检测发现MDS缓存使用又超过新设定值的1.5倍大小了。此时，可以考虑设置多个活动状态的MDS服务。

• # 先开启3台服务器的MDS服务，确保这3台服务器的内存是够用的，最好这3台服务器的内存更大。
• ceph orch apply mds cephfs ceph106,ceph107,ceph109
• ceph fs set cephfs max_mds 3
• # 由于激活了3台服务器的MDS，缺少备用的MDS服务。再增加一个备用的MDS服务主机。
• ceph orch apply mds cephfs ceph106,ceph107,ceph109,ceph110
  

5. Client node18 failing to respond to cache pressure

表示node18主机和MDS服务之前的响应较慢，若过一会儿就显示health_ok，则不用管它。若是长期显示该警告，则在对应的node18主机上卸载ceph文件系统后重新挂载即可。

客户端在使用相应数据时，MDS服务端则将其数据缓存到服务器的内存中。当MDS服务端需要减少缓存消耗时，则会给客户端发送相应的请求。此时，客户端响应过慢，则提示此警告信息。若一直如此，会导致MDS服务器缓存无法释放，内存消耗持续增加甚至导致宕机。

ceph集群提供元数据服务，则客户端可以提挂载ceph文件系统。客户端访问数据时，则在客户端和元数据服务器中都缓存相应的数据。元数据服务器会和客户端inode占用情况来消减缓存。当客户端响应太慢，则会报错“failing to respond to cache pressure” or MDS_HEALTH_CLIENT_RECALL。若确实是客户端负荷较大，是正常读写操作，可以考虑增大mds_recall_warning_decay_rate参数的值（默认为60s），从而消除警告。

可以查询ceph客户端的ID号及其使用inode数（num_caps的值）。

• ceph tell mds.0 session ls
  2 p! L8 W& y( W) C+ g0 ?- @" I

谨慎使用如下命令踢出目标客户端或全部客户端。

• ceph tell mds.0 session evict id=11134635
• ceph tell mds.0 session evict
    p& y4 I6 D& O( W8 O

踢出客户端是将客户端加入了黑名单，可以使用如下命令查看黑名单信息或移出黑名单。虽然移出黑名单，可能还不能让客户端正常挂载ceph文件系统，因此需要谨慎处理。

• ceph osd blacklist ls
• ceph osd blacklist rm 192.168.20.1:0/1498586492
• ceph osd blacklist clear
  ) Q7 X; B/ k" X7 O3 S

6. Reduced data availability: 4 pgs inactive, 4 pgs incomplete

当有pgs出现incomplete时，表明pgs对应的OSDs存活数量少于最小副本数。因此，其对应的数据无法读写，处于reduced状态，会导致MDS服务出问题，提示如下报错信息，示例：

• 3 MDSs report slow metadata IOs
• 2 MDSs report slow requests
• 2 MDSs behind on trimming
• Reduced data availability: 4 pgs inactive, 4 pgs incomplete
• pg 5.6de is incomplete, acting [254,356,222,352,111,247,100,133,351,206 (reducing pool cephfs_data min_size from 8 may help; search ceph.com/docs for 'incomplete')
• pg 5.6e9 is incomplete, acting [276,244,357,358,221,321,311,229,314,351 (reducing pool cephfs_data min_size from 8 may help; search ceph.com/docs for 'incomplete')
• pg 5.73b is incomplete, acting [186,279,351,247,293,354,359,220,181,283 (reducing pool cephfs_data min_size from 8 may help; search ceph.com/docs for 'incomplete')
• pg 5.eda is incomplete, acting [164,157,120,227,353,351,295,269,95,354 (reducing pool cephfs_data min_size from 8 may help; search ceph.com/docs for 'incomplete')
  

此时，需要修复pgs。

• # 查询pg信息（pg id 为 5.6de）
• ceph pg 5.6de query
• # 强行重建pg
• ceph osd force-create-pg 5.6de --yes-i-really-mean-it
  9 G# c, f# u* q2 u, E5 A

7. failed to probe daemons or devices stderr:Non-zero exit code 125 from /bin/podman

由于Ceph存储集群中个别服务器的podman容器出问题，导致相应服务启动失败。报告警告如下：

• [WRN CEPHADM_REFRESH_FAILED: failed to probe daemons or devices
• host ceph105 ceph-volume inventory failed: cephadm exited with an error code: 1, stderr:Non-zero exit code 125 from /bin/podman run --rm --ipc=host --net=host --entrypoint stat -e CONTAINER_IMAGE=docker.io/ceph/ceph:v15 -e NODE_NAME=ceph105 docker.io/ceph/ceph:v15 -c %u %g /var/lib/ceph
• stat:stderr Error: readlink /var/lib/containers/storage/overlay/l/HMGABIBEWBRXOSBT4JLOKQIKDA: no such file or directory
• Traceback (most recent call last):
• File "", line 6112, in
• File "", line 1299, in _infer_fsid
• File "", line 1382, in _infer_image
• File "", line 3581, in command_ceph_volume
• File "", line 1477, in make_log_dir
• File "", line 2084, in extract_uid_gid
• RuntimeError: uid/gid not found
  

执行以下命令时，会有如上报错。而正常的存储节点则不会报错。

• cephadm shell
  2 k0 T* Y  D- ?- i- a4 s

该类报错表示podman的docker容器出错。查找出错的存储节点：

• ceph orch ps | grep error
  " p$ N* C# Y- h, z3 c8 Q" ~% S: f* S. S

在各存储节点重新pull相应的docker镜像：

• cephadm pull
• podman pull ceph/ceph:v15
• # 以上两个命令都可以达到目的，后者能看到下载的速度，以免等待较长时间下载几百M的文件而不清楚进度。
• # 重新pull镜像后，会提升ceph版本。不会影响使用
  

检查podman的docker镜像

• podman images
• podman ps
  7 W0 `1 E: J7 u4 T/ i' o

最后重启服务器或重启CEPH服务。

8. mds.cephfs.ceph109.avzzqn(mds.1): Behind on trimming (594/128) max_segments: 128, num_segments: 594

有MDS服务器报警：

• [WRN MDS_TRIM: 2 MDSs behind on trimming
• mds.cephfs.ceph109.avzzqn(mds.1): Behind on trimming (594/128) max_segments: 128, num_segments: 594
• mds.cephfs.ceph106.hggsge(mds.0): Behind on trimming (259/128) max_segments: 128, num_segments: 259
  2 @2 G! {0 Q/ v* e& c( j

MDS服务器将元数据以segments(object)方式存放，当MDS中的segments数量超出mds_log_max_segments的设置值（默认为128）时，MDS服务开始启动Trimming，即将segments数据进行回写。当MDS中的segments数超过设定值两倍时，开始报警Behind on trimming信息。当MDS服务器内存足够时，推荐增大mds_log_max_segments参数值。

• ceph config set mds mds_log_max_segments 1024
  2 M# m' M  V5 U- G% B$ R1 ~

9. mds N slow requests are blocked > 30 secs

MDS服务报警：

• [WRN MDS_SLOW_REQUEST: 3 MDSs report slow requests
• mds.cephfs.ceph109.avzzqn(mds.1): 29 slow requests are blocked > 30 secs
• mds.cephfs.ceph110.sfagxf(mds.2): 1 slow requests are blocked > 30 secs
• mds.cephfs.ceph106.hggsge(mds.0): 3 slow requests are blocked > 30 secs
  $ t" `9 W, b* T8 _

以上报警表示MDS响应慢，原因可能是：mds服务运行太慢、底层pg或OSD出问题导致写入日志未确认、或BUG。通过设置mds_op_complaint_time值为3000，问题依旧。

出现此警告时，OSD未报错。而mds服务运行应该正常，内存也足够用。通过阵列卡检测硬盘，发现有两台服务器分别有一块硬盘没有检测到。推测是相应的硬盘出问题，而OSD还未反应过来，带后续观察。

10. insufficient standby MDS daemons available

当有mds服务crash的时候，候选的mds则补上。此时，已经连接上的计算服务器还是可以正常访问ceph存储。但是，新的计算服务器无法挂载ceph文件系统。

解决方法是，ssh登陆到mds服务有crash的服务器，然后重启其mds服务。再登陆备用的mds服务器，重启其mds服务。

• ssh ceph107
• systemctl restart ceph-8f1c1f24-59b1-11eb-aeb6-f4b78d05bf17@mds.cephfs.ceph106.hggsge.service
• ssh ceph102
• systemctl restart ceph-8f1c1f24-59b1-11eb-aeb6-f4b78d05bf17@mds.cephfs.ceph102.imxzno.service
  7 G) T2 F7 s. q% O. H

! w/ i' E' B( f7 Y1 ^! o3 _

# s* V4 e; k/ Y& F

admin

开始
此前，博客有更新一篇关于cephfs的文章 - 小试牛刀，主要是cephfs的一些基本的使用，版本也是比较早期的12版本
+ l1 A& l* d! t& e1 S7 A! F8 X5 k* a
0 q: s- w/ g5 }" I# r4 c1 [此后不少读者和我探讨过cephfs的情况，我给出的建议一律是：cephfs不建议上生产，不稳定

时至今日，cephfs经过了多个版本的迭代开发，据说可以上生产了，这里我们对其进行一些列的测试
+ L+ @3 y4 o/ y9 B7 W( L
测试是这样，先使用了13.2.10版本进行测试，然后使用14.2.20进行相同的测试，测试环境:
3 j  J& c0 v: }% y
data pool 使用ec 4+2

$ n0 `  y9 |- {* ?+ b" W2 O写入大文件(64GiB)
- w. B; p& k* F
) [5 t# p) ~' q8 G5 ^0 V写入大量较小小文件(4MiB+1MiB)
" l( ?9 c# d0 k7 t1 B
. e$ [) ~0 u9 T  u4 C4 [5 W- ~写满pool后进行纯粹的读取
% s( r8 ]) S, m6 w$ N
写入时重启某个rank

/ D3 i$ N+ \* K* j( O13版本的情况
写入大文件(64GiB)写满pool，这个没有问题，写满pool也不用多少个文件，读取也顺利

6 K" |/ i( ]- e8 }/ E5 R+ t写入大量较小的文件就不行了，读取也不能正常进行
% @" \5 d3 x/ g$ m5 t
, T5 T3 f9 K. u0 D7 h* S2 A7 E6 ?默认配置下，cephfs的根目录下创建10个目录，写入大量的文件

; O* u1 H9 S9 |5 D! B! X! s[twj@R03-MTEST-DN-017.xx.cn ~]$ sudo ceph fs status
9 E6 E7 Z( Z: }' g* wfilecephfs - 3 clients
==========
+------+--------+------------------------+---------------+-------+-------+
7 d3 [4 {/ Y( m2 U6 s0 F| Rank | State  |          MDS           |    Activity   |  dns  |  inos |
% @; x* I0 _$ C+------+--------+------------------------+---------------+-------+-------+
5 T) L- E( f3 P2 {|  0   | active | R03-MTEST-MN-002.xx.cn | Reqs:    0 s | 19.8M | 19.8M |
+------+--------+------------------------+---------------+-------+-------+
+----------------------+----------+-------+-------+
|         Pool         |   type   |  used | avail |
" j$ U/ Q! X7 e! Z' b+----------------------+----------+-------+-------+
5 D5 K  K  M$ O5 Q9 m4 ]5 Q| cephfs-metadata-pool | metadata |  155M |  794G |
5 y' S; g# q$ N/ [6 G) u$ q|   cephfs-data-pool   |   data   |  957T |    0  |
9 W% Y/ M8 G7 h3 k+----------------------+----------+-------+-------+
. z7 l" F6 v; h" e4 D0 d2 D" z6 a+------------------------+
|      Standby MDS       |
4 l; q/ i2 y, c( l' ?+------------------------+
/ g+ c. U# H4 M+ J) l5 d% Z| R03-MTEST-MN-001.xx.cn |
4 s' a# u9 \3 v: ~+------------------------+
4 Q, I" K  P) s/ DMDS version: ceph version 13.2.10 (564bdc4ae87418a232fc901524470e1a0f76d641) mimic (stable)
[twj@R03-MTEST-MN-001.xx.cn ~]$ sudo ceph df
8 _' r% o) j; X0 B" _5 q  C; E# b1 wGLOBAL:
/ Y" a  ?% f" g* u% D# F6 E    SIZE        AVAIL      RAW USED     %RAW USED
    1.5 PiB     91 TiB      1.4 PiB         94.08
POOLS:
    NAME                     ID     USED        %USED      MAX AVAIL     OBJECTS
    cephfs-data-pool         15     957 TiB     100.00           0 B     561286578
! m0 x. @' {0 l" P4 m7 m/ _8 `    cephfs-metadata-pool     17     155 MiB       0.02       795 GiB         98368

) L6 L6 I: M8 S! G& b/ {+ t+ v此时，mds的内存占用达到了55g
1 Y1 y/ K' G% W* C
    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  47740 ceph      20   0   55.4g  55.0g  10356 S   6.6 21.9  11905:23 ceph-mds
' n- `3 ]; U* A7 e
尝试重启这个mds，直接导致fs瘫痪，mds状态一直都是replay，接着mon好几天都起不来，集群也直接没法用了。。。

2021-06-17 10:10:36.352 7f9039544700  1 heartbeat_map is_healthy 'Monitor::cpu_tp thread 0x7f9034ccc700' had timed out after 0
5 ], L4 T; T; J
' D- e. e! o1 i# Yperf top -p 3563473
! j! G2 i3 V8 m3 W* A! OSamples: 63K of event 'cycles:ppp', Event count (approx.): 49402841395
Overhead  Shared Object         Symbol
  48.92%  libceph-common.so.0   [.] crush_hash32_3
  24.28%  libceph-common.so.0   [.] 0x0000000000647f80
/ M5 i- V+ \* Q, u( s   4.35%  libceph-common.so.0   [.] 0x0000000000647f59

第二次测试，写入一段时间后，集群报错，mds处于rejoin状态

  cluster:
    id:     8418d616-979b-46f9-ab95-b8fb20093d1b
    health: HEALTH_WARN
            1 filesystem is degraded
/ n+ D) o3 I: p- d            1 MDSs report oversized cache
            1 MDSs report slow metadata IOs
9 ]8 F1 s9 d5 Z5 G+------+--------+----------------------+----------+-------+-------+
| Rank | State  |         MDS          | Activity |  dns  |  inos |
6 `9 P. e, I/ q. ~4 l9 u+------+--------+----------------------+----------+-------+-------+
  T4 w6 C  e  q) n2 K5 i& f|  0   | rejoin |R03-MTEST-MN-001.xx.cn|          | 59.5M | 59.5M |
+------+--------+----------------------+----------+-------+-------+

7 {. o4 d$ `, ~4 J此时mds的内存消耗非常大

- A: X$ M% z; V5 W+ Z, ]0 u    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
150540 ceph      20   0  224.9g 223.5g  11704 S 100.0 89.0 196:15.69 ceph-mds

* e! A+ H7 |% k% K4 S+ N' B使用命令ceph daemon run/ceph/ceph-mds.R03-MTEST-MN-001.xx.cn.asok flush journal
后，降低了一些，但很快又上到了223G
! m8 C- @- j: R& K% L5 m& B
从结果上看，该版本的mds主要是没有解决内存的问题，没写多少文件，内存就直线飙升，而且居高不下，妄想重启mds，那就直接玩完

. G  B: T8 d/ x. |0 f6 b7 R这里直接给出13.2.10的建议：不行！事实上，14.2.x之前的版本都不建议使用cephfs上生产环境
, \! N* x) I' K7 b( z
/ E9 {" C2 H. N1 |14版本的表现
在这个版本的测试用，我加入了额外的data pool，并使用了多活mds，直接测试的小文件写入
! t8 _0 k) z3 x* @2 j3 z9 l) ?
[twj@R03-MTEST-MN-001.xx.cn test-cephfs]$ sudo ceph fs status
! ^1 i3 g# @. [. Fcephfs - 40 clients
( b! h) L. e* J# x, O======
+------+--------+------------------------+---------------+-------+-------+
: s8 e8 |' {$ |" m+ O4 m  ?& m+ t| Rank | State  |          MDS           |    Activity   |  dns  |  inos |
2 \: i+ `' q! \$ j* o+------+--------+------------------------+---------------+-------+-------+
; A) i" B& m5 [# S; R9 b|  0   | active | R03-MTEST-MN-003.xx.cn | Reqs: 10.3k/s |  391k |  391k |
|  1   | active | R03-MTEST-MN-002.xx.cn | Reqs: 10.5k/s |  385k |  385k |
- u$ G0 U8 _( _$ U+------+--------+------------------------+---------------+-------+-------+
+----------------------+----------+-------+-------+
' \2 u. F( d4 e, G  z|         Pool         |   type   |  used | avail |
" {" A4 s3 I  ]* B0 e: ?+----------------------+----------+-------+-------+
0 ]# P# Y0 ]4 @/ h' V& B  T| cephfs.metadata.pool | metadata | 3378M |  797G |
|  cephfs.data.pool1   |   data   | 6085G | 1234T |
" N! q5 k) e: ?# r|  cephfs.data.pool2   |   data   | 2257G | 1241T |
( S$ B  Y0 m; O/ {$ S, Q- }( m6 e+----------------------+----------+-------+-------+
+------------------------+
) p: H) \( ?$ y" l|      Standby MDS       |
. b8 A: b, E$ L3 x+------------------------+
& R: M! `5 \6 {! ?3 K* ~| R03-MTEST-MN-001.xx.cn |
+------------------------+
MDS version: ceph version 14.2.20 (36274af6eb7f2a5055f2d53ad448f2694e9046a0) nautilus (stable)

其中每个data pool都创建了20个目录，并pin到不同的mds上，性能看还算均衡，连续快速写入，会有告警2 MDSs behind on trimming
但没有什么影响，就没管
; Q  f' p. _4 T
) o3 p3 b) C. `4 U2 l5 V; L随着数据的大量写入，集群开始出现slow

[twj@R03-MTEST-MN-001.xx.cn ~]$ sudo ceph df
9 D4 x& E1 y: p; B5 ]RAW STORAGE:
, n% b8 T  |! E& E; k2 A, b    CLASS     SIZE        AVAIL       USED        RAW USED     %RAW USED
    hdd       3.9 PiB     3.1 PiB     823 TiB      823 TiB         20.79
4 J- F! z2 w$ i% {" f4 a: T    ssd        16 TiB     3.0 TiB      13 TiB       13 TiB         80.72
  e! ?* ]; E' L    TOTAL     3.9 PiB     3.1 PiB     835 TiB      836 TiB         21.03

POOLS:
    POOL                     ID     PGS      twjD      OBJECTS     USED        %USED     MAX AVAIL
    cephfs.data.pool1         2     8192     275 TiB     217.81M     413 TiB     23.20       911 TiB
: e8 q0 I" z* Q: L7 m& X- q) ~# m3 N    cephfs.data.pool2         3     8192     244 TiB     102.44M     366 TiB     20.53       946 TiB
    cephfs.metadata.pool      4      256     127 GiB     115.39k     191 GiB      7.74       760 GiB
   
, G# I  X; u( x! q' J4 w[twj@R03-MTEST-MN-001.xx.cn ~]$ sudo ceph health detail
HEALTH_WARN 1 MDSs report slow metadata IOs; 1 MDSs report slow requests
MDS_SLOW_METADATA_IO 1 MDSs report slow metadata IOs
    mds.R03-MTEST-MN-002.xx.cn(mds.1): 100+ slow metadata IOs are blocked > 30 secs, oldest blocked for 87 secs
MDS_SLOW_REQUEST 1 MDSs report slow requests
4 i4 T4 r  v) A    mds.R03-MTEST-MN-002.xx.cn(mds.1): 11 slow requests are blocked > 30 secs

查看mds的op处理流程
7 `& R6 x, I) H3 v, l6 q1 w1 R  @( p
. E/ S" _" x- U' ^' _[twj@R03-MTEST-MN-002.xx.cn ~]$ sudo ceph daemon mds.`hostname` dump_historic_ops_by_duration|grep duration
    "duration": 600,
            "duration": 427.63886984499999,
            "duration": 427.62001601499998,
1 g6 o& w/ H& J* l8 [            "duration": 409.772382456,
7 N! [) i  q" I, f5 c6 L+ E            "duration": 409.75990740399999,
0 s% ]" |. R7 Y3 X% W3 h9 M2 {# w            "duration": 215.47288510800001,
            "duration": 214.47418489699999,
            "duration": 203.97045117499999,
            "duration": 203.51505527899999,
" k7 Q! P# W, m; S" [2 n            ...

) S! T7 L9 q4 i) c2 p6 @+ P时间都非常久，继续排查，发现大量的op都是卡在failed to rdlock, waiting
这个步骤，关于这种情况的调查和优化，还在努力。。。
, ?+ g+ I$ R! V* C4 G! @& O! b2 C
看了一眼内存，没有明显的飙升
* t4 C3 f# E# x, U9 o
[twj@R03-MTEST-MN-003.xx.cn ~]$ top
top - 15:34:57 up 9 days,  4:36,  1 user,  load average: 0.95, 1.22, 1.28
Tasks: 650 total,   1 running, 649 sleeping,   0 stopped,   0 zombie
% n& c% s. I6 y- y' Y- j& c; z/ E5 J%Cpu(s):  1.9 us,  0.1 sy,  0.0 ni, 98.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
# R" }) C% K0 j  @* v0 X; _2 w/ [KiB Mem : 26353089+total, 25013656+free, 11907872 used,  1486464 buff/cache
4 p, D+ N& o, ~: L! e& @' c5 jKiB Swap: 16777212 total, 16777212 free,        0 used. 24535932+avail Mem
* {3 a' L2 Z# L
    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  29657 ceph      20   0 7878864   2.5g  14288 S 100.7  1.0   4616:55 ceph-mds
# s. u; p+ k/ p5 Y: P
大量数据写入后，先测试一下mds的重启，直接reboot节点，观察集群的情况
& W5 _, k4 ^% B. Q( ]
7 K+ U" h3 t4 m# J1 o[twj@R03-MTEST-MN-002.xx.cn ~]$ sudo ceph fs status
cephfs - 40 clients
======
+------+--------+------------------------+---------------+-------+-------+
| Rank | State  |          MDS           |    Activity   |  dns  |  inos |
4 W& Z/ l5 o6 H/ B4 R+------+--------+------------------------+---------------+-------+-------+
. A9 _3 `% o. z) ?" W  t|  0   | active | R03-MTEST-MN-001.xx.cn | Reqs:  869 s |  445k |  445k |
|  1   | active | R03-MTEST-MN-002.xx.cn | Reqs:    0 s |  365k |  365k |
8 S, T7 D8 R. C0 C* \2 S+------+--------+------------------------+---------------+-------+-------+
+----------------------+----------+-------+-------+
* _) O2 R; T9 `) F1 u+ m: d' h& N|         Pool         |   type   |  used | avail |
. r, a: J! r5 j9 z+----------------------+----------+-------+-------+
| cephfs.metadata.pool | metadata |  186G |  762G |
7 P( j4 [! d% N2 K/ r|  cephfs.data.pool1   |   data   |  412T |  910T |
0 Z3 w+ S# c: _|  cephfs.data.pool2   |   data   |  366T |  945T |
, {/ H* O% W" c: ]+----------------------+----------+-------+-------+
2 l# D* R5 h/ q+------------------------+
- w2 j) y+ n5 J5 ?1 T|      Standby MDS       |
+------------------------+
/ z; O- p/ F) ^| R03-MTEST-MN-003.xx.cn |
" s5 I! z4 Y- B/ [7 }# I+------------------------+
MDS version: ceph version 14.2.20 (36274af6eb7f2a5055f2d53ad448f2694e9046a0) nautilus (stable)
; x" F5 G( s+ t
0 t  @. q3 @6 V( S+ F* w看是备是直接顶上了，mds重启后自动做备，业务侧暂时没有发现有问题，不过，发现写入的流量都打到了同一个mds，不知道是不是因为rank序号变化导致的
7 W+ N1 k% f0 w4 D' c# T
测试发现，当单个目录对象数达到千万级时，cephfs的目录出现明显的卡顿，测试读，读取偶尔会有问题，流量不稳定，最大可到1GiB/s，最小只有几百M
% E0 J5 O1 s7 D* W1 _1 a
  io:
! P' B# S) O5 `# H% V3 Z2 b    client:   240 MiB/s rd, 559 KiB/s wr, 102 op/s rd, 0 op/s wr

结论
* j( I6 B! B0 P& N! C" Icephfs 14.2.20测试结果来看，稳定性可靠性还是可以的，至少内存的问题看来是解决了，没有出现持续大量数据写入时产生的高内存占用问题，同时，重启其中一个rank，备用的mds会自动顶上，业务没有太大影响，而且，目录内的文件数量只要不是太大，小于百万级的话，性能也没有太大的问题，因此，14.2.20及后续版本的cephfs应该是可以上生产的了
# q' U. T8 k, J, R
反观此前的版本，12、13都比较拉垮，mds不太靠谱，如果client有故障，读写卡住，mds分分钟给你瘫痪，极具危险性，还是不建议上，如果已经有在线的fs，还是强烈建议迁移到14.2.20+的版本

下一步，将继续测试cephfs的其他异常情况和大规模数据写入后slow req的问题，并对代码逻辑方面进行一些分析，敬请期待^_^
$ U6 i7 J9 ^; U. j( [" u

admin

一、pg相关#
+ k, [* L; R/ T3 G: L( f: y3 ^1、xx objects unfound#
- 问题描述：#
dmesg查看磁盘发现读写异常，部分对象损坏（处于objects nofound状态），集群处于ERR状态
( i- [9 ]5 P" V* I/ Z* G  F2 v
4 _( i8 g( v* K% `6 `$ yroot@node1101:~# ceph health detail
! E5 W$ A! A0 \5 ~1 vHEALTH_ERR noscrub,nodeep-scrub flag(s) set; 13/409798 objects unfound(0.003%)；17 stuck requests are blocked > 4096 sec. Implicated osds 38
- o) P, V7 d! F/ G9 R! FOSDMAP_FLAGS noscrub,nodeep-scrub flag(s) set
OBJECT_UNFOUND 13/409798 objects unfound (0.003%)
  pg 5.309 has 1 unfound objects
  pg 5.2da has 1 unfound objects
  pg 5.2c9 has 1 unfound objects
  pg 5.1e2 has 1 unfound objects
  pg 5.6a has 1 unfound objects
  pg 5.120 has 1 unfound objects
7 _2 D4 I3 ]' n+ l9 R  pg 5.148 has 1 unfound objects
  pg 5.14b has 1 unfound objects
  pg 5.160 has 1 unfound objects
  pg 5.35b has 1 unfound objects
$ S. k8 c/ Z. I  pg 5.39c has 1 unfound objects
  pg 5.3ad has 1 unfound objects
: P0 A( B. L3 ?: k2 s0 g  PREQUEST_STUCK 17 stuck requests are blocked > 4096 sec. Implicated osds 38
  17 ops are blocked > 67108.9 sec
6 U: u4 u4 ^1 z" r8 D  }4 F- O  osd.38 has stuck requests > 67108.9 sec
- 处理措施：#
将unfound pg强制删除，参考命令：ceph pg {pgid} mark_unfound_lost delete
注：如需批量删除unfound pg，则参考命令如下
; \! e1 Y1 N7 Y: f* m: B. p
for i in `ceph health detail | grep pg | awk '{print $2}'`;do ceph pg $i mark_unfound_lost delete;done
. L3 I0 v- Q1 Q0 t, T2、Reduced data availability: xx pgs inactive#
. [6 l1 G3 b0 @( J- 问题描述：#
磁盘出现读写异常，osd无法启动，强制替换故障盘为新盘加入到集群，出现pgs inactive（unkown）

root@node1106:~# ceph -s
2 ]. k2 I1 @, ~: }$ ^  cluster:
8 G0 [& D/ H* |9 _7 E( h    id:     7f1aa879-afbb-4b19-9bc3-8f55c8ecbbb4
    health: HEALTH_WARN
3 X: w3 D0 Q7 p3 m            4 clients failing to respond to capability release
            3 MDSs report slow metadata IOs
            1 MDSs report slow requests
            3 MDSs behind on trimming
5 R' s  ]' y- j, J1 f: e            noscrub,nodeep-scrub flag(s) set
2 Q$ k; c* L5 Z            Reduced data availability: 25 pgs inactive
9 t7 U" k. n, j5 q/ P            6187 slow requests are blocked > 32 sec. Implicated osds 41


$ v+ n2 K8 Z/ O  B: B+ \. {3 q  services:
' D5 [  X1 {! C: O    mon: 3 daemons, quorum node1101,node1102,node1103
    mgr: node1103(active), standbys: node1102, node1101
    mds: ceph-3/3/3 up  {0=node1103=up:active,1=node1102=up:active,2=node1104=up:active}, 2 up:standby
$ Z* ?4 n! j8 r" w7 t1 @    osd: 48 osds: 48 up, 48 in
         flags noscrub,nodeep-scrub
+ T5 X4 l% H( S' f! `+ K
' Q; {) b8 r- a7 G
1 `" V9 B/ i7 q5 R1 T, F+ F  data:
    pools:   6 pools, 2888 pgs
    objects: 474.95k objects, 94.5GiB
    usage:   267GiB used, 202TiB / 202TiB avail
9 w$ w' J7 d, I5 {: z# R+ p    pgs:     0.866% pgs unknown
             2863 active+clean
             25   unknown
5 ]6 r! O; w& j7 w6 I

root@node1101:~# ceph pg dump_stuck inactive
ok
PG_STAT STATE   UP UP_PRIMARY ACTING ACTING_PRIMARY
! O# |4 l1 _4 |$ Y$ B0 ]+ @1.166   unknown []         -1     []             -1
* y, Q# ]" P1 u$ c9 Y1.163   unknown []         -1     []             -1
! F  D) a! z8 U7 D; N1.26f   unknown []         -1     []             -1
1.228   unknown []         -1     []             -1
1.213   unknown []         -1     []             -1
- U/ c& W% U# j5 A( [% J1.12f   unknown []         -1     []             -1
1.276   unknown []         -1     []             -1
1.264   unknown []         -1     []             -1
- _+ X) E- k) {/ f% t- b1.32a   unknown []         -1     []             -1
1.151   unknown []         -1     []             -1
' K9 j2 A3 J! A- B/ [" S1 v  C1.20d   unknown []         -1     []             -1
1 r' t! Y  b9 b2 B6 k" D1.298   unknown []         -1     []             -1
. {( ^4 q; q6 Q3 G  X* E/ w3 Y1.306   unknown []         -1     []             -1
1.2f7   unknown []         -1     []             -1
/ g7 G- m+ T( ?& n. A1.2c8   unknown []         -1     []             -1
5 q; U+ D+ e- {) ^  ^: Z, l1.223   unknown []         -1     []             -1
1.204   unknown []         -1     []             -1
1.374   unknown []         -1     []             -1
1.b5    unknown []         -1     []             -1
1.b6    unknown []         -1     []             -1
1.2b    unknown []         -1     []             -1
1.9f    unknown []         -1     []             -1
1.2ac   unknown []         -1     []             -1
1.78    unknown []         -1     []             -1
1.1c3   unknown []         -1     []             -1
1.1a    unknown []         -1     []             -1
1.d9    unknown []         -1     []             -1
1 {5 Q9 ]! {8 b8 i. m- 处理措施：#
强制创建unkown pg，参考命令：ceph osd force-create-pg {pgid}
注：如需批量创建unkown pg，则参考命令如下：

for i in `ceph pg dump_stuck inactive | awk '{if (NR>2){print $1}}'`;do ceph osd force-create-pg $i;done
二、OSD相关#
1、osd端口与其他服务固定绑定端口冲突#
- 问题描述：#
osd先行启动，占用其他服务固定绑定端口，导致其他服务绑定端口失败，无法启动

1 g; R4 l; q5 ?, ^8 j- 处理措施：#
; S. {+ `) E; d, e$ r- h考虑到其他服务涉及组件太多，担心修改不完全导致其他问题发生，尝试修改osd启动端口范围为其他服务之外

( ^* q: `+ o( Q修改osd作为服务端的启动端口范围
0 D5 s/ I$ I% }ceph可通过ms_bind_port_min和ms_bind_port_max参数限制osd和mds守护进程使用端口范围，默认范围为6800：7300
设置端口使用范围为9600:10000，追加参数设置至/etc/ceph/ceph.conf文件中[global]字段内
; Q: f4 c+ u, U, Z[root@node111 ~]# cat /etc/ceph/ceph.conf | grep ms_bind_port
$ B3 l2 `: |3 a/ Mms_bind_port_min = 9600
ms_bind_port_max = 10000
[root@node111 ~]#
0 @% D+ P. F; H. _2 i& m[root@node111 ~]# ceph --show-config | grep ms_bind_port
$ K9 v5 F5 |! G- d; vms_bind_port_max = 10000
ms_bind_port_min = 9600
: ]+ V, J, p/ Q" d" R修改osd作为客户端的启动端口范围
' z! }' g. E- wosd作为客户端的启动端口为随机分配的，可通过内核去限制随机端口分配范围
默认端口范围为1024：65000，修改端口范围为7500：65000
; K4 `# Z. A4 r# w--默认端口范围为1024：65000
[root@node111 ~]# cat /proc/sys/net/ipv4/ip_local_port_range
1024    65000
9 s: `; `. Q. n--修改范围为7500：65000
[root@node111 ~]# sed -i 's/net.ipv4.ip_local_port_range=1024 65000/net.ipv4.ip_local_port_range=7500 65000/g' /etc/sysctl.conf
[root@node111 ~]# sysctl -p
& M: n7 w' F1 ]4 n' U% c; k. ?2、磁盘热插拔，osd无法上线#
9 p; g" f1 l2 ?  L! r- 问题描述：#
使用bluestore部署ceph集群，对osd所在磁盘进行热插拔操作，当重新插回之后，osd对应lvm不能自动恢复，导致osd无法上线成功
/ Q) d% E( d# n% }# L* w: u
3 X7 V% B0 p" X1 Y- H$ a
+ Y* I& H: f+ }* O6 Q0 W9 s
2 J! z: V" m1 N8 s0 p2 v2 ?7 B- 处理措施：#
查找故障osd对应uuid：
ceph osd dump | grep {osd-id} | awk '{print $NF}'
参考示例：查找osd.0对应uuid
  T$ y4 f& F" `[root@node127 ~]# ceph osd dump | grep osd.0 | awk '{print $NF}'
) w- w# E3 E  V5 V+ O2 G: r57377809-fba4-4389-8703-f9603f16e60d
查找故障osd对应lvm路径：
9 i- h/ M$ X. w: N; W+ Pls /dev/mapper/ | grep `ceph osd dump | grep {osd-id} | awk '{print $NF}' | sed 's/-/--/g'`
参考示例：通过uuid查找对应lvm路径
5 ~* f1 }" E1 V! A& L( B注：由于lvm路径对uuid做了处理，需要sed 's/-/--/g'`将-替换为--
; V# [; \9 u" l) J( a( w+ W[root@node127 ~]# ls /dev/mapper/ | grep `ceph osd dump | grep osd.0 | awk '{print $NF}' | sed 's/-/--/g'`
- e* {! e7 M) `# u6 j( S6 Sceph--3182c42e--f8d8--4c13--ad92--987463d626c8-osd--block--57377809--fba4--4389--8703--f9603f16e60d
5 g. F: v" J4 m1 @" `删除故障osd对应lvm路径
2 G/ u! {6 y  W9 ?! r- ]2 D% Odmsetup remove /dev/mapper/{lvm-path}
参考示例：删除故障osd对应lvm路径
[root@node127 ~]# dmsetup remove /dev/mapper/ceph--3182c42e--f8d8--4c13--ad92--987463d626c8-osd--block--57377809--fba4--4389--8703--f9603f16e60d
重新激活所有lvm卷组
注：此时可以查看到对应故障osd的lvm信息
vgchange -ay
重新启动osd使得osd上线
systemctl start ceph-volume@lvm-{osd-id}-{osd-uuid}
三、集群相关#
1 n$ c8 `* [) ]1 O1、clock skew detected on mon.node2#
/ a2 A; D/ T. z/ A- 问题描述：#
集群mon节点时间偏差过大，出现clock skew detected on mon.node2 告警信息

- 处理措施：#
1、检查集群mon节点时间偏差，使用chronyd时间进行集群时间同步
) z% z8 R3 |4 B: w9 n' o2、调大集群参数阈值，调整mon_clock_drift_allowed 参数值为2，调整mon_clock_drift_warn_backoff 参数值为30

sed -i "2 amon_clock_drift_allowed = 2" /etc/ceph/ceph.conf
sed -i "3 amon_clock_drift_warn_backoff = 30" /etc/ceph/ceph.conf
9 ?3 M* Q9 x7 Jceph tell mon.* injectargs '--mon_clock_drift_allowed 2'
ceph tell mon.* injectargs '--mon_clock_drift_warn_backoff 30'
+ `7 Q. A7 h( Z5 V7 R! w$ C- q7 E# R注：相关参数说明如下：

[root@node147 ~]# ceph --show-config | grep mon_clock_drift
( F* w! G8 {1 _" r6 L6 C4 e" Umon_clock_drift_allowed = 0.050000
--当mon节点之间时间偏移超过0.05秒，则不正常
5 C5 Y- Y  `8 ^2 D# _mon_clock_drift_warn_backoff = 5.000000
' F0 u- {- A- o% U--当出现5次偏移，则上报告警