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

admin

[root@8-5 ~]# ceph health detail
& Z0 D4 p& U9 p1 dHEALTH_WARN 1 MDSs report slow metadata IOs; 1 MDSs report slow requests
[WRN] MDS_SLOW_METADATA_IO: 1 MDSs report slow metadata IOs
/ k8 H, `$ V' ^3 s    mds.cephfs.gm268-2.xdsdoz(mds.0): 100+ slow metadata IOs are blocked > 30 secs, oldest blocked for 2718 secs
5 c6 T  G# I$ e' D[WRN] MDS_SLOW_REQUEST: 1 MDSs report slow requests
    mds.cephfs.gm268-2.xdsdoz(mds.0): 73 slow requests are blocked > 30 secs

4 @+ w" X* v( c5 o. y- n
出现这种提示会导致集群对请求没有反应，解决办法就是重启所有的ceph节点即可：
systemctl restart ceph.target或者重启服务器也可解决问题，响应慢可以使用重启的方式来重新发起集群数据均衡。
  }5 y& u# h4 A5 |
观察结果

3 ]( S  a* r  q
; F: q$ }9 [* I% e

1 e9 W' f: U* O1. Slow OSD heartbeats

• # ceph -s
• health: HEALTH_WARN
•        Slow OSD heartbeats on back (longest 6181.010ms)
•        Slow OSD heartbeats on front (longest 5953.232ms)
  9 a# \4 {& G& e, v' J0 L8 O9 w

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
  

应该是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
  ) M" c$ V. |* f1 D8 `8 y6 `$ ?

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

• ceph tell mds.0 session evict id=11134635
• ceph tell mds.0 session evict
  

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

• ceph osd blacklist ls
• ceph osd blacklist rm 192.168.20.1:0/1498586492
• ceph osd blacklist clear
  3 o, w2 U1 K# K: l9 f+ d# n

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')
  - R# o  [& f; A- l! ]

此时，需要修复pgs。

• # 查询pg信息（pg id 为 5.6de）
• ceph pg 5.6de query
• # 强行重建pg
• ceph osd force-create-pg 5.6de --yes-i-really-mean-it
  

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
  1 x% v  J5 g- [" Y

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

• ceph orch ps | grep error
  

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

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

检查podman的docker镜像

• podman images
• podman ps
  

最后重启服务器或重启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
  

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
  

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
  ' E3 G" @7 }" v% T9 c

以上报警表示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
  

admin

开始
此前，博客有更新一篇关于cephfs的文章 - 小试牛刀，主要是cephfs的一些基本的使用，版本也是比较早期的12版本

% a4 x/ {9 ^" v; I# L; \0 G' Q) d+ x; A此后不少读者和我探讨过cephfs的情况，我给出的建议一律是：cephfs不建议上生产，不稳定
9 d4 {3 Q0 y2 f6 R
时至今日，cephfs经过了多个版本的迭代开发，据说可以上生产了，这里我们对其进行一些列的测试

测试是这样，先使用了13.2.10版本进行测试，然后使用14.2.20进行相同的测试，测试环境:

data pool 使用ec 4+2

写入大文件(64GiB)
$ J0 Y! h8 P1 X! j, C
写入大量较小小文件(4MiB+1MiB)

写满pool后进行纯粹的读取

写入时重启某个rank
  j  R0 I) ]: m2 c4 M. G. X
: l8 }- |+ f& |( e6 F13版本的情况
写入大文件(64GiB)写满pool，这个没有问题，写满pool也不用多少个文件，读取也顺利
+ T; l# Q+ k# [: J1 X& o- t8 w
- R* M! B0 K4 b' M! v0 Z写入大量较小的文件就不行了，读取也不能正常进行
( F; a$ w- M1 h
; j7 N7 l* N, S默认配置下，cephfs的根目录下创建10个目录，写入大量的文件
/ p: ~- ]! x: Y, ?- M  |
[twj@R03-MTEST-DN-017.xx.cn ~]$ sudo ceph fs status
filecephfs - 3 clients
8 c! M' T+ f$ x  D4 K3 `+ _, ~==========
+------+--------+------------------------+---------------+-------+-------+
+ I" T% F; f$ j/ p| Rank | State  |          MDS           |    Activity   |  dns  |  inos |
+------+--------+------------------------+---------------+-------+-------+
2 j4 Z8 p7 @) @$ ^0 j7 P1 b1 b|  0   | active | R03-MTEST-MN-002.xx.cn | Reqs:    0 s | 19.8M | 19.8M |
$ @% [& v3 G5 \7 |. }+------+--------+------------------------+---------------+-------+-------+
+----------------------+----------+-------+-------+
|         Pool         |   type   |  used | avail |
+----------------------+----------+-------+-------+
| cephfs-metadata-pool | metadata |  155M |  794G |
$ v2 B% A! n1 m|   cephfs-data-pool   |   data   |  957T |    0  |
2 F8 ?1 T! q) o6 ?* O! S7 l3 Q6 u+----------------------+----------+-------+-------+
+------------------------+
1 U; l& m6 \$ D|      Standby MDS       |
" J1 Q! i# i3 U" ?+------------------------+
; _& p9 U, v* E6 Y| R03-MTEST-MN-001.xx.cn |
+------------------------+
MDS version: ceph version 13.2.10 (564bdc4ae87418a232fc901524470e1a0f76d641) mimic (stable)
[twj@R03-MTEST-MN-001.xx.cn ~]$ sudo ceph df
0 C  H' X' o8 N: w: _+ l2 JGLOBAL:
    SIZE        AVAIL      RAW USED     %RAW USED
! L4 p( R6 f0 t# c    1.5 PiB     91 TiB      1.4 PiB         94.08
2 c5 ^; d# g' YPOOLS:
, _5 r* s) s& o/ \4 Y    NAME                     ID     USED        %USED      MAX AVAIL     OBJECTS
    cephfs-data-pool         15     957 TiB     100.00           0 B     561286578
    cephfs-metadata-pool     17     155 MiB       0.02       795 GiB         98368

此时，mds的内存占用达到了55g
. c& Q; v/ c" U/ Y: u& \
8 U% y0 i/ j0 w( o5 E    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
7 Q$ J7 O! B5 U% y- z0 K% |! }5 _  47740 ceph      20   0   55.4g  55.0g  10356 S   6.6 21.9  11905:23 ceph-mds

& E. Y& N. t" |% l- B尝试重启这个mds，直接导致fs瘫痪，mds状态一直都是replay，接着mon好几天都起不来，集群也直接没法用了。。。

, N3 S7 V7 c( ^! C0 J3 T2021-06-17 10:10:36.352 7f9039544700  1 heartbeat_map is_healthy 'Monitor::cpu_tp thread 0x7f9034ccc700' had timed out after 0
9 g* r4 h- t9 t" T! V
  x: g. @# u5 yperf top -p 3563473
$ ~0 @; z" w# \/ ]; {+ q8 _Samples: 63K of event 'cycles:ppp', Event count (approx.): 49402841395
1 ~6 F& ], o9 ~& cOverhead  Shared Object         Symbol
$ z8 H2 x9 K8 ~7 p$ d" X& G) k5 D  48.92%  libceph-common.so.0   [.] crush_hash32_3
/ B1 k# O5 G' P0 V1 {! {  24.28%  libceph-common.so.0   [.] 0x0000000000647f80
5 I" S6 f; e- W% h   4.35%  libceph-common.so.0   [.] 0x0000000000647f59

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

  cluster:
    id:     8418d616-979b-46f9-ab95-b8fb20093d1b
    health: HEALTH_WARN
            1 filesystem is degraded
/ k/ V3 A4 ~$ i: e) G) [            1 MDSs report oversized cache
7 G' s- Q% K1 b) ~$ L9 k  O' i            1 MDSs report slow metadata IOs
+------+--------+----------------------+----------+-------+-------+
5 }1 M+ V3 X& _| Rank | State  |         MDS          | Activity |  dns  |  inos |
0 l; l' N# ~  l, |+------+--------+----------------------+----------+-------+-------+
|  0   | rejoin |R03-MTEST-MN-001.xx.cn|          | 59.5M | 59.5M |
+------+--------+----------------------+----------+-------+-------+

此时mds的内存消耗非常大
( q  E; Z- ^* u* ^# p" }
    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

! \, C/ Q& f- }7 \8 f' A$ c使用命令ceph daemon run/ceph/ceph-mds.R03-MTEST-MN-001.xx.cn.asok flush journal
' w9 ~/ G' j/ F5 V' S后，降低了一些，但很快又上到了223G
4 u- W: Z8 ~- n* ]  O. ?' h
9 g6 [+ i& \# d2 Z9 }8 z从结果上看，该版本的mds主要是没有解决内存的问题，没写多少文件，内存就直线飙升，而且居高不下，妄想重启mds，那就直接玩完

' f9 g7 g* e% R; @- U7 ]这里直接给出13.2.10的建议：不行！事实上，14.2.x之前的版本都不建议使用cephfs上生产环境
+ w0 g: Q5 g  B$ X2 j& m7 r
1 f8 M; S; h' B# s14版本的表现
在这个版本的测试用，我加入了额外的data pool，并使用了多活mds，直接测试的小文件写入

[twj@R03-MTEST-MN-001.xx.cn test-cephfs]$ sudo ceph fs status
* b& S' {! V5 S8 ~cephfs - 40 clients
& v/ O0 W# A8 V9 R4 [5 r======
2 Y8 M* a. w# ^* ^+------+--------+------------------------+---------------+-------+-------+
| Rank | State  |          MDS           |    Activity   |  dns  |  inos |
+------+--------+------------------------+---------------+-------+-------+
5 E# i0 W$ B. a! p3 q; ||  0   | active | R03-MTEST-MN-003.xx.cn | Reqs: 10.3k/s |  391k |  391k |
6 X  t& }8 b9 Q/ j3 D|  1   | active | R03-MTEST-MN-002.xx.cn | Reqs: 10.5k/s |  385k |  385k |
7 ^; D3 S8 L$ ~6 w. X+------+--------+------------------------+---------------+-------+-------+
+----------------------+----------+-------+-------+
|         Pool         |   type   |  used | avail |
+----------------------+----------+-------+-------+
8 I: Q4 x6 G$ ?| cephfs.metadata.pool | metadata | 3378M |  797G |
|  cephfs.data.pool1   |   data   | 6085G | 1234T |
+ g$ {/ k0 y7 Y7 F( A! w$ }|  cephfs.data.pool2   |   data   | 2257G | 1241T |
+----------------------+----------+-------+-------+
+------------------------+
|      Standby MDS       |
+------------------------+
| R03-MTEST-MN-001.xx.cn |
+------------------------+
% s5 R9 {% X" w' z. b* z6 ]8 IMDS version: ceph version 14.2.20 (36274af6eb7f2a5055f2d53ad448f2694e9046a0) nautilus (stable)

其中每个data pool都创建了20个目录，并pin到不同的mds上，性能看还算均衡，连续快速写入，会有告警2 MDSs behind on trimming
% r: Q5 B$ `% z但没有什么影响，就没管
, A* G$ I5 u6 |, ^4 N- A& D# z, J
随着数据的大量写入，集群开始出现slow

- t! }# G. e  U% s8 O- X[twj@R03-MTEST-MN-001.xx.cn ~]$ sudo ceph df
( V, D; d8 u" n  c! L# MRAW STORAGE:
" }2 p+ O5 Y7 |( t: _    CLASS     SIZE        AVAIL       USED        RAW USED     %RAW USED
    hdd       3.9 PiB     3.1 PiB     823 TiB      823 TiB         20.79
9 q3 s( g- ?; Z0 _' m    ssd        16 TiB     3.0 TiB      13 TiB       13 TiB         80.72
- W: k0 t- x: a& V' E/ n3 L    TOTAL     3.9 PiB     3.1 PiB     835 TiB      836 TiB         21.03
5 v. g# m- \( y8 F
6 b2 M( v, z) k0 c$ x; w1 j0 CPOOLS:
  ^& V( B9 t/ N7 W: p% v4 m# _    POOL                     ID     PGS      twjD      OBJECTS     USED        %USED     MAX AVAIL
    cephfs.data.pool1         2     8192     275 TiB     217.81M     413 TiB     23.20       911 TiB
    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
   
1 T9 h6 \4 o9 O8 b6 Y8 }3 J  x[twj@R03-MTEST-MN-001.xx.cn ~]$ sudo ceph health detail
5 T3 E( q8 F  l$ AHEALTH_WARN 1 MDSs report slow metadata IOs; 1 MDSs report slow requests
5 D" o) p1 t6 X( t4 F0 k8 v" m9 NMDS_SLOW_METADATA_IO 1 MDSs report slow metadata IOs
# k" M* N3 J. |8 S7 m5 Q- r    mds.R03-MTEST-MN-002.xx.cn(mds.1): 100+ slow metadata IOs are blocked > 30 secs, oldest blocked for 87 secs
- [) g; j; S7 ]# q3 TMDS_SLOW_REQUEST 1 MDSs report slow requests
    mds.R03-MTEST-MN-002.xx.cn(mds.1): 11 slow requests are blocked > 30 secs

查看mds的op处理流程
8 _/ V# |& a+ D; B# _0 P
, L7 k& b' Q- ]) m) m" ]- x[twj@R03-MTEST-MN-002.xx.cn ~]$ sudo ceph daemon mds.`hostname` dump_historic_ops_by_duration|grep duration
% [4 |4 g( W# [. Q    "duration": 600,
            "duration": 427.63886984499999,
            "duration": 427.62001601499998,
            "duration": 409.772382456,
            "duration": 409.75990740399999,
" J- p( l" j6 U6 z4 q            "duration": 215.47288510800001,
/ h% ]% y, I- j; Z8 s) l) X; a; G            "duration": 214.47418489699999,
7 t  q8 X, G, ~# z9 z  ~            "duration": 203.97045117499999,
            "duration": 203.51505527899999,
* K* W# [; b. F# X/ i: e+ C  {            ...
7 V7 H& i1 R2 U* N2 ~( N0 K0 a6 S
时间都非常久，继续排查，发现大量的op都是卡在failed to rdlock, waiting
这个步骤，关于这种情况的调查和优化，还在努力。。。
- E8 a) n$ L, F6 y
! @; m0 ^3 M9 E& y/ P看了一眼内存，没有明显的飙升
9 X! i! g7 V- a
5 U6 ]# P7 G. g# L) k. ~/ d  x/ }7 s$ P[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
: p% H% r5 w6 t' gTasks: 650 total,   1 running, 649 sleeping,   0 stopped,   0 zombie
%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
KiB Mem : 26353089+total, 25013656+free, 11907872 used,  1486464 buff/cache
9 x+ N/ T7 W2 j' ?1 gKiB Swap: 16777212 total, 16777212 free,        0 used. 24535932+avail Mem

( H% r& \. @! j5 K    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

大量数据写入后，先测试一下mds的重启，直接reboot节点，观察集群的情况

. g7 s; _. O- f[twj@R03-MTEST-MN-002.xx.cn ~]$ sudo ceph fs status
cephfs - 40 clients
: f& T% |9 H$ q: R+ ]3 u: E======
0 [# @& a( q* q1 @  x7 I+------+--------+------------------------+---------------+-------+-------+
! T9 w, y0 I" r( i/ b1 D; [6 J| Rank | State  |          MDS           |    Activity   |  dns  |  inos |
+ G; C+ B: R; j! s( @1 h% V+------+--------+------------------------+---------------+-------+-------+
|  0   | active | R03-MTEST-MN-001.xx.cn | Reqs:  869 s |  445k |  445k |
8 |5 P4 \6 F* b* |% J! P0 \|  1   | active | R03-MTEST-MN-002.xx.cn | Reqs:    0 s |  365k |  365k |
+------+--------+------------------------+---------------+-------+-------+
1 @  ^$ P& l7 V5 y: j+----------------------+----------+-------+-------+
|         Pool         |   type   |  used | avail |
+----------------------+----------+-------+-------+
| cephfs.metadata.pool | metadata |  186G |  762G |
|  cephfs.data.pool1   |   data   |  412T |  910T |
; K) w* H7 M2 p( y3 o3 V% u|  cephfs.data.pool2   |   data   |  366T |  945T |
- M' K- L: o9 X* O; K; Y7 y% N+----------------------+----------+-------+-------+
+------------------------+
|      Standby MDS       |
2 a: \5 ~; n. ]+------------------------+
8 v  p- W. ^. v+ Q2 ^3 `$ E% x| R03-MTEST-MN-003.xx.cn |
+------------------------+
MDS version: ceph version 14.2.20 (36274af6eb7f2a5055f2d53ad448f2694e9046a0) nautilus (stable)
7 v1 }0 h1 }+ `8 ~
: E- C! M: E3 r, ?看是备是直接顶上了，mds重启后自动做备，业务侧暂时没有发现有问题，不过，发现写入的流量都打到了同一个mds，不知道是不是因为rank序号变化导致的
6 ~, T/ J% Q" Q  |* K" F
7 n. e4 U7 K0 L* p; I" `1 U测试发现，当单个目录对象数达到千万级时，cephfs的目录出现明显的卡顿，测试读，读取偶尔会有问题，流量不稳定，最大可到1GiB/s，最小只有几百M
! i* q7 \0 _1 Z9 v5 v9 {
' I% D0 \: `* U2 G/ x  io:
    client:   240 MiB/s rd, 559 KiB/s wr, 102 op/s rd, 0 op/s wr

. Q. r1 f' B" Y: c: |3 {+ G9 t结论
cephfs 14.2.20测试结果来看，稳定性可靠性还是可以的，至少内存的问题看来是解决了，没有出现持续大量数据写入时产生的高内存占用问题，同时，重启其中一个rank，备用的mds会自动顶上，业务没有太大影响，而且，目录内的文件数量只要不是太大，小于百万级的话，性能也没有太大的问题，因此，14.2.20及后续版本的cephfs应该是可以上生产的了
; O8 R% l5 M9 Y' [' y0 m
反观此前的版本，12、13都比较拉垮，mds不太靠谱，如果client有故障，读写卡住，mds分分钟给你瘫痪，极具危险性，还是不建议上，如果已经有在线的fs，还是强烈建议迁移到14.2.20+的版本

  L0 I  r% A7 p& M& x- D- c5 p$ D2 {下一步，将继续测试cephfs的其他异常情况和大规模数据写入后slow req的问题，并对代码逻辑方面进行一些分析，敬请期待^_^

admin

一、pg相关#
7 R5 G+ u$ H8 U% b) T" ~% P7 Z1、xx objects unfound#
- 问题描述：#
dmesg查看磁盘发现读写异常，部分对象损坏（处于objects nofound状态），集群处于ERR状态

root@node1101:~# ceph health detail
, t# ~; J8 O  K. ~2 n, E) k$ `HEALTH_ERR noscrub,nodeep-scrub flag(s) set; 13/409798 objects unfound(0.003%)；17 stuck requests are blocked > 4096 sec. Implicated osds 38
9 S! h4 z2 ~9 X. q* [* Q7 OOSDMAP_FLAGS noscrub,nodeep-scrub flag(s) set
' [. U% E& S, L0 n* {OBJECT_UNFOUND 13/409798 objects unfound (0.003%)
% x  d, m, ^4 L2 g4 U3 K4 ^9 A  pg 5.309 has 1 unfound objects
4 b& R* r/ l) d' C  pg 5.2da has 1 unfound objects
  pg 5.2c9 has 1 unfound objects
% D7 \6 j; A4 P5 `, E: ^& a  pg 5.1e2 has 1 unfound objects
6 K/ k+ a) a& M  pg 5.6a has 1 unfound objects
/ w/ L3 P1 K  m4 j5 M& }  pg 5.120 has 1 unfound objects
7 J0 R* s' k8 M/ d# e6 P  pg 5.148 has 1 unfound objects
! W* ]. e, c3 V) S. [* b2 S  pg 5.14b has 1 unfound objects
- b- @! ~5 E* F, g, g5 f  pg 5.160 has 1 unfound objects
6 a  [: _; M: ?/ q( Q  pg 5.35b has 1 unfound objects
+ T+ L2 n, N) y  pg 5.39c has 1 unfound objects
  pg 5.3ad has 1 unfound objects
" v( V" N3 a7 z% OREQUEST_STUCK 17 stuck requests are blocked > 4096 sec. Implicated osds 38
  17 ops are blocked > 67108.9 sec
7 s% e/ I) K" G! h0 F6 s5 [! J; ~; S2 U  osd.38 has stuck requests > 67108.9 sec
; A* f6 |+ l4 D% v4 v' [- 处理措施：#
- _( q# p& p* a9 r, C" g将unfound pg强制删除，参考命令：ceph pg {pgid} mark_unfound_lost delete
' ]- j" ?& N8 }; v2 o# U. X6 \注：如需批量删除unfound pg，则参考命令如下

for i in `ceph health detail | grep pg | awk '{print $2}'`;do ceph pg $i mark_unfound_lost delete;done
: m0 @3 D" @0 Z- s2、Reduced data availability: xx pgs inactive#
/ S: ^9 a0 P' ]! u" F- 问题描述：#
6 L+ s# o; H$ P  p* }5 q- G: J7 o磁盘出现读写异常，osd无法启动，强制替换故障盘为新盘加入到集群，出现pgs inactive（unkown）

root@node1106:~# ceph -s
: g& l& E+ u  a# q4 f2 M  cluster:
+ E% m, Z0 s5 m/ s9 g    id:     7f1aa879-afbb-4b19-9bc3-8f55c8ecbbb4
    health: HEALTH_WARN
: [, K% e- m# G; @/ k9 [1 B: `            4 clients failing to respond to capability release
            3 MDSs report slow metadata IOs
            1 MDSs report slow requests
  q* S3 y6 v" |8 J            3 MDSs behind on trimming
            noscrub,nodeep-scrub flag(s) set
9 {, H, I6 z! x0 W; ^+ q9 A5 }" }            Reduced data availability: 25 pgs inactive
2 n( p0 A0 L0 N" ?* @  v5 r9 r            6187 slow requests are blocked > 32 sec. Implicated osds 41
1 v& c3 y8 m: z
3 I. {& h, c7 ]5 f1 r
  services:
    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
5 |. I2 C0 t- j    osd: 48 osds: 48 up, 48 in
         flags noscrub,nodeep-scrub
% z6 ^) B4 G0 Z6 D( |
1 L; N2 v& H( B( @2 h. b5 y# ]4 T
  data:
9 T9 o. o( E( W    pools:   6 pools, 2888 pgs
    objects: 474.95k objects, 94.5GiB
    usage:   267GiB used, 202TiB / 202TiB avail
    pgs:     0.866% pgs unknown
             2863 active+clean
             25   unknown

/ P4 D& ?3 F" K; ~' B( @: Z
8 D6 x7 j) F' N- U! l+ t% |9 r4 l: _root@node1101:~# ceph pg dump_stuck inactive
7 S# ?6 I; l. {* bok
PG_STAT STATE   UP UP_PRIMARY ACTING ACTING_PRIMARY
1.166   unknown []         -1     []             -1
9 H" P* Z/ ]; m1.163   unknown []         -1     []             -1
1.26f   unknown []         -1     []             -1
7 T) S2 y7 S) I0 D. \1.228   unknown []         -1     []             -1
4 p* U, X+ q) p8 _; ]1.213   unknown []         -1     []             -1
1.12f   unknown []         -1     []             -1
1.276   unknown []         -1     []             -1
! t3 n0 k+ ^: `/ S3 V. T1.264   unknown []         -1     []             -1
: N, ]) R! ~( o9 c1.32a   unknown []         -1     []             -1
1 t& B5 X. |) G  v/ I  c# q) d1.151   unknown []         -1     []             -1
1.20d   unknown []         -1     []             -1
1.298   unknown []         -1     []             -1
& {- s/ ^" |/ M- x4 g1.306   unknown []         -1     []             -1
1.2f7   unknown []         -1     []             -1
1.2c8   unknown []         -1     []             -1
1.223   unknown []         -1     []             -1
7 F) M# u" A* r# @1.204   unknown []         -1     []             -1
1.374   unknown []         -1     []             -1
1.b5    unknown []         -1     []             -1
, I4 C, Y2 t5 O* h1.b6    unknown []         -1     []             -1
5 m* Y6 a# W) q/ F2 [0 v' T1 C9 ~' G1.2b    unknown []         -1     []             -1
8 j( _4 N' a; C' y1.9f    unknown []         -1     []             -1
1.2ac   unknown []         -1     []             -1
1.78    unknown []         -1     []             -1
1.1c3   unknown []         -1     []             -1
! @+ M; A5 O* ~& U4 ~( Z  ^1.1a    unknown []         -1     []             -1
. y7 f/ N7 f8 H7 F2 ~0 j1.d9    unknown []         -1     []             -1
- 处理措施：#
强制创建unkown pg，参考命令：ceph osd force-create-pg {pgid}
注：如需批量创建unkown pg，则参考命令如下：

, a+ q$ W* a/ f$ ofor i in `ceph pg dump_stuck inactive | awk '{if (NR>2){print $1}}'`;do ceph osd force-create-pg $i;done
二、OSD相关#
1、osd端口与其他服务固定绑定端口冲突#
- 问题描述：#
( c, L" k% ~+ W6 d& mosd先行启动，占用其他服务固定绑定端口，导致其他服务绑定端口失败，无法启动
) J. [2 Q( l! k5 Y- I
) @  Q. }! Y' u1 Q  S8 v- 处理措施：#
考虑到其他服务涉及组件太多，担心修改不完全导致其他问题发生，尝试修改osd启动端口范围为其他服务之外

: D* r; D) s( I. v9 A  C# b修改osd作为服务端的启动端口范围
, f( K: a+ J' D* u( j3 T7 ~7 Qceph可通过ms_bind_port_min和ms_bind_port_max参数限制osd和mds守护进程使用端口范围，默认范围为6800：7300
/ ]7 u6 g* f# T( H1 O1 N设置端口使用范围为9600:10000，追加参数设置至/etc/ceph/ceph.conf文件中[global]字段内
[root@node111 ~]# cat /etc/ceph/ceph.conf | grep ms_bind_port
ms_bind_port_min = 9600
ms_bind_port_max = 10000
[root@node111 ~]#
! Q! I: ?" I1 U( q2 n$ F& A: X" ][root@node111 ~]# ceph --show-config | grep ms_bind_port
- P5 y# w5 }5 b3 z3 R  [/ Ims_bind_port_max = 10000
  z+ U) W# b" k/ Pms_bind_port_min = 9600
修改osd作为客户端的启动端口范围
osd作为客户端的启动端口为随机分配的，可通过内核去限制随机端口分配范围
& |) b* I1 G5 l; z默认端口范围为1024：65000，修改端口范围为7500：65000
--默认端口范围为1024：65000
' |% [* ]5 G, j* H# `$ K[root@node111 ~]# cat /proc/sys/net/ipv4/ip_local_port_range
1024    65000
--修改范围为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
- r6 I  V, d8 o2 P2、磁盘热插拔，osd无法上线#
- 问题描述：#
3 l' P) O8 M2 m6 R& L使用bluestore部署ceph集群，对osd所在磁盘进行热插拔操作，当重新插回之后，osd对应lvm不能自动恢复，导致osd无法上线成功

) G6 Q) y' ~( E. y( @
6 O  d- ~' P* Z1 I! @2 ~' }$ D
- 处理措施：#
/ x3 z* o2 J; a3 O查找故障osd对应uuid：
ceph osd dump | grep {osd-id} | awk '{print $NF}'
7 c' D4 a1 T! e# k参考示例：查找osd.0对应uuid
[root@node127 ~]# ceph osd dump | grep osd.0 | awk '{print $NF}'
. j  }4 l5 O$ J57377809-fba4-4389-8703-f9603f16e60d
2 v8 t" z; {, H4 H2 W: h( C6 Y* l7 V: T查找故障osd对应lvm路径：
& I7 S9 E1 W( O! mls /dev/mapper/ | grep `ceph osd dump | grep {osd-id} | awk '{print $NF}' | sed 's/-/--/g'`
" O7 D6 A0 u4 @* E2 W9 L参考示例：通过uuid查找对应lvm路径
; x1 I  |$ _" q  s. g* A5 [注：由于lvm路径对uuid做了处理，需要sed 's/-/--/g'`将-替换为--
! l& b4 M; ?3 R9 V& A[root@node127 ~]# ls /dev/mapper/ | grep `ceph osd dump | grep osd.0 | awk '{print $NF}' | sed 's/-/--/g'`
3 J, F" L0 z" ~, V( e+ I0 n. gceph--3182c42e--f8d8--4c13--ad92--987463d626c8-osd--block--57377809--fba4--4389--8703--f9603f16e60d
* t2 B1 O& e. {( ?删除故障osd对应lvm路径
; Z" v1 j! w( ^+ L( _dmsetup remove /dev/mapper/{lvm-path}
参考示例：删除故障osd对应lvm路径
) y: [: {, _! d[root@node127 ~]# dmsetup remove /dev/mapper/ceph--3182c42e--f8d8--4c13--ad92--987463d626c8-osd--block--57377809--fba4--4389--8703--f9603f16e60d
8 s& k, g/ `  @6 a: B重新激活所有lvm卷组
注：此时可以查看到对应故障osd的lvm信息
vgchange -ay
* ]: _+ _  Y& h# |/ Y: V4 T重新启动osd使得osd上线
systemctl start ceph-volume@lvm-{osd-id}-{osd-uuid}
- A( K; g8 H' g( P+ r4 w三、集群相关#
1、clock skew detected on mon.node2#
; H) L( _/ Q# p- `" N% ?5 i- 问题描述：#
/ c' K: l- o! }" A8 l$ O5 o集群mon节点时间偏差过大，出现clock skew detected on mon.node2 告警信息
4 U1 ]& _1 \' c% e& c- X& K
- 处理措施：#
1、检查集群mon节点时间偏差，使用chronyd时间进行集群时间同步
# Q. d4 P% ]1 F2、调大集群参数阈值，调整mon_clock_drift_allowed 参数值为2，调整mon_clock_drift_warn_backoff 参数值为30

+ w$ F1 s  j7 M; Q: @) rsed -i "2 amon_clock_drift_allowed = 2" /etc/ceph/ceph.conf
sed -i "3 amon_clock_drift_warn_backoff = 30" /etc/ceph/ceph.conf
ceph tell mon.* injectargs '--mon_clock_drift_allowed 2'
4 b2 m' m3 l8 ]( l1 \& u( j  f* D# bceph tell mon.* injectargs '--mon_clock_drift_warn_backoff 30'
) z  e3 [& p  M6 K注：相关参数说明如下：

[root@node147 ~]# ceph --show-config | grep mon_clock_drift
- [2 Y. h$ ?% G+ Mmon_clock_drift_allowed = 0.050000
  |( H4 l# M- X. K--当mon节点之间时间偏移超过0.05秒，则不正常
mon_clock_drift_warn_backoff = 5.000000
--当出现5次偏移，则上报告警