浏览此站
联系我们相册切换到窄版 Language

 找回密码
 注册
易陆发现论坛»论坛 › 云计算开源区 › ceph分布式存储 › cephfs 提示MDS_SLOW_METADATA_IO: 1 MDSs report slow ...
返回列表 发新帖
查看: 615|回复: 2

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

[复制链接]
admin

0

主题

0

回帖

9

积分

管理员

积分
9
QQ
发表于 2023-2-3 11:13:00 | 显示全部楼层 |阅读模式
[root@8-5 ~]# ceph health detail
$ c) G. u( ^% H  W  h/ ZHEALTH_WARN 1 MDSs report slow metadata IOs; 1 MDSs report slow requests
. ~0 ^( {8 ^/ U1 M$ s[WRN] MDS_SLOW_METADATA_IO: 1 MDSs report slow metadata IOs+ A4 R5 R2 X' \3 s* h  J& h
    mds.cephfs.gm268-2.xdsdoz(mds.0): 100+ slow metadata IOs are blocked > 30 secs, oldest blocked for 2718 secs
7 Y; A3 Z6 u8 o& d, v) r[WRN] MDS_SLOW_REQUEST: 1 MDSs report slow requests5 ~  N8 Z+ {% z/ \
    mds.cephfs.gm268-2.xdsdoz(mds.0): 73 slow requests are blocked > 30 secs6 X4 n$ u. V6 _  j3 l; W* ~( G

4 O5 K/ W: d5 g+ s  T, b3 D  j4 u2 A
出现这种提示会导致集群对请求没有反应，解决办法就是重启所有的ceph节点即可：
9 n3 I0 E& H& l# h( Nsystemctl restart ceph.target或者重启服务器也可解决问题，响应慢可以使用重启的方式来重新发起集群数据均衡。" ~  X& |% k# A8 \! \8 T) `
+ \0 h5 K* |. q" S7 z
观察结果
9 M) R5 m" G$ ~) e. [# |- W; u6 ?& i' G) |& U6 v- V  S2 @' [

5 t' F' S! ^5 s' M% q% q
; J2 J+ l; e. T* j
) a+ D9 h" n- g* i1. Slow OSD heartbeats
  • # ceph -s
  • health: HEALTH_WARN
  •        Slow OSD heartbeats on back (longest 6181.010ms)
  •        Slow OSD heartbeats on front (longest 5953.232ms)0 l% `2 ]* _2 Z. b0 w% A$ \
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延迟都比较高，将该主机的光纤网线拔下擦拭干净并重新插上得以解决。8 }' C- b1 ?. E( k/ k5 }
2. slow ops
  • # ceph -s
  •      21 slow ops, oldest one blocked for 29972 sec, mon.ceph1 has slow ops% b$ M4 R" D' J* S0 E
先保证所有存储服务器上的时间同步一致，再重启相应主机上的moniter服务解决。
3. pgs not deep-scrubbed in time
  • # ceph -s
  •     47 pgs not deep-scrubbed in time
    . b. S' G. [# X1 `, W7 ^9 \
应该是OSDs掉线后，CEPH自动进行数据恢复。再将相应的OSDs重新加入后，则需要将恢复的数据再擦除掉。于是提示相应的警告信息，正在进行删除相关的操作，且其pgs的数量会不断变少。等待一段时间后，则恢复正常，此时ceph文件系统性能很差。
4. MDS cache is too large
  • ceph config set mds mds_cache_memory_limit 10GB
  • ceph config dump5 \$ ?9 q( d7 Y! ^/ v) j) d
当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' Y- N3 u; Y! S6 H( j* Z9 O
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
    6 ]# W6 t5 e, `' f* u/ k
谨慎使用如下命令踢出目标客户端或全部客户端。
  • ceph tell mds.0 session evict id=11134635
  • ceph tell mds.0 session evict
    % }+ u* y& ~* L
踢出客户端是将客户端加入了黑名单，可以使用如下命令查看黑名单信息或移出黑名单。虽然移出黑名单，可能还不能让客户端正常挂载ceph文件系统，因此需要谨慎处理。
  • ceph osd blacklist ls
  • ceph osd blacklist rm 192.168.20.1:0/1498586492
  • ceph osd blacklist clear
    ) O" ~; O0 U0 E  {' L
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')
    6 D9 @5 f3 T/ J+ B
此时，需要修复pgs。
  • # 查询pg信息（pg id 为 5.6de）
  • ceph pg 5.6de query
  • # 强行重建pg
  • ceph osd force-create-pg 5.6de --yes-i-really-mean-it
    5 t" c1 r3 Z, n5 R% n1 F
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 found5 k! A4 X' B! N! X- s
执行以下命令时，会有如上报错。而正常的存储节点则不会报错。
  • cephadm shell* b1 D: y. \! U4 u& [2 r" Z2 X8 m9 E
该类报错表示podman的docker容器出错。查找出错的存储节点：
  • ceph orch ps | grep error- W; ]2 d: v3 C" c# g
在各存储节点重新pull相应的docker镜像：
  • cephadm pull
  • podman pull ceph/ceph:v15
  • # 以上两个命令都可以达到目的，后者能看到下载的速度，以免等待较长时间下载几百M的文件而不清楚进度。
  • # 重新pull镜像后，会提升ceph版本。不会影响使用
    ' G; V# H# N% A1 Y1 J3 q- l
检查podman的docker镜像
  • podman images
  • podman ps
    ; G8 e- [/ N6 y) w1 U( ?
最后重启服务器或重启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. M2 S% P% Q) Z$ ]8 U
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  {' b1 `" o- D4 h- {7 {' I+ s
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
    9 o. g4 w! U7 `- s$ `. t
以上报警表示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
    6 ^* z8 w4 p7 K0 j, |7 {; q- o9 U2 v
- q' {4 U$ j# \3 s/ b6 T

! ?1 v$ y" I) S  N7 e9 `/ j; k* F8 D7 y# j) Z5 [* h# C
回复

举报

admin

0

主题

0

回帖

9

积分

管理员

积分
9
QQ
 楼主| 发表于 2023-2-3 17:26:18 | 显示全部楼层
开始% i- B( E5 j; u  q2 @
此前，博客有更新一篇关于cephfs的文章 - 小试牛刀，主要是cephfs的一些基本的使用，版本也是比较早期的12版本1 \3 {7 N8 ^  h! d
  {( E$ @' V* `, \3 V
此后不少读者和我探讨过cephfs的情况，我给出的建议一律是：cephfs不建议上生产，不稳定# [" B1 z8 K% I# h5 g
0 Q- R$ M( R% F1 O* C; I# i
时至今日，cephfs经过了多个版本的迭代开发，据说可以上生产了，这里我们对其进行一些列的测试& u$ a$ R$ ~% U( e  W

5 [6 z( O" f4 Y- p测试是这样，先使用了13.2.10版本进行测试，然后使用14.2.20进行相同的测试，测试环境:
7 X& _! h; j; \) p( t, S' \2 i7 L; E
data pool 使用ec 4+2. N& t, e8 z( K/ n5 k% g4 M

1 D, L# X, q/ N1 p. l4 E. `: y写入大文件(64GiB)
6 ]8 M& W- T) E6 g' D, |$ Q: g5 x9 S+ x$ Q+ Q) x
写入大量较小小文件(4MiB+1MiB): [8 V6 o0 d/ e+ h2 `3 \
' x/ F- O3 W: Q& ]4 H$ I
写满pool后进行纯粹的读取
; U! ~* M/ r! m5 g% X' Y4 F
$ r* R* Y% r! A% N8 A写入时重启某个rank
; g( l6 A: X6 v- _2 p# d& b3 t* g; I, i3 u% D1 D
13版本的情况
1 _0 v' G/ Y# ]1 i  q写入大文件(64GiB)写满pool，这个没有问题，写满pool也不用多少个文件，读取也顺利
8 K- j3 V/ s. R4 P$ S
$ Q: D+ Q8 b+ E' l: ]9 x( [' i写入大量较小的文件就不行了，读取也不能正常进行: y- l1 W" ]8 B6 b. B) H: h

' A/ k) {& q! l: Y. {  \默认配置下，cephfs的根目录下创建10个目录，写入大量的文件9 [8 z# Z9 p4 ]: Z4 j
/ p* {% I, O& I1 A9 u
[twj@R03-MTEST-DN-017.xx.cn ~]$ sudo ceph fs status
; K/ w' o1 C3 I  x8 Xfilecephfs - 3 clients9 r0 q5 R! z2 A6 R
==========5 {7 F2 R( x9 x& D) A& N
+------+--------+------------------------+---------------+-------+-------+
7 I. @- b1 z, W/ ?! v# X6 N) L. z| Rank | State  |          MDS           |    Activity   |  dns  |  inos |! A8 A4 V+ f6 _; J- H; R( J
+------+--------+------------------------+---------------+-------+-------+6 H9 J) R: W. q# e) j
|  0   | active | R03-MTEST-MN-002.xx.cn | Reqs:    0 s | 19.8M | 19.8M |
: y8 x8 Z& h) z0 T( }& W1 z: Z+------+--------+------------------------+---------------+-------+-------+" Y5 u$ m: g' `. C$ o( L( P
+----------------------+----------+-------+-------+
. B1 B  u1 G/ z6 J0 [/ Q' N* r|         Pool         |   type   |  used | avail |& k' O! Q2 ~% l0 h
+----------------------+----------+-------+-------+/ j( V7 ?/ }  N
| cephfs-metadata-pool | metadata |  155M |  794G |  ~$ H9 v# f$ N) ]( [
|   cephfs-data-pool   |   data   |  957T |    0  |2 D/ j" V  V# M" l0 T
+----------------------+----------+-------+-------+1 t; g+ s, [; Q$ O  O6 C
+------------------------+5 `+ q+ k; H: C# Z& b% X
|      Standby MDS       |+ a- y! i! x" ^2 o
+------------------------+% o; ], J% a- ~
| R03-MTEST-MN-001.xx.cn |
4 Y" S5 l* O3 ^! G* t5 t5 M9 C& F+------------------------+9 a, `2 K$ y* A2 E/ s! K
MDS version: ceph version 13.2.10 (564bdc4ae87418a232fc901524470e1a0f76d641) mimic (stable)$ U2 F. b* j  T
[twj@R03-MTEST-MN-001.xx.cn ~]$ sudo ceph df1 b) k5 h0 Y. D% K) I: A
GLOBAL:  h% O7 f( ^# _% ~  y
    SIZE        AVAIL      RAW USED     %RAW USED
: t, h/ }  v" d5 i, m    1.5 PiB     91 TiB      1.4 PiB         94.08
8 X5 F1 n! n/ w* ?  t6 c& ]6 f; jPOOLS:
  p' a% F- u) ]' \. M    NAME                     ID     USED        %USED      MAX AVAIL     OBJECTS0 M* }! I& [& }! z4 R* z, g! N, M0 D
    cephfs-data-pool         15     957 TiB     100.00           0 B     5612865785 a. k" g( c1 o- B
    cephfs-metadata-pool     17     155 MiB       0.02       795 GiB         983688 n2 j/ A1 Y3 u7 D3 g/ q8 X' p# P
. s! x+ L& ^- C/ H4 @8 r7 V
此时，mds的内存占用达到了55g
; w1 p! u' P9 g
6 T% s2 C) ]% v2 S: |' x2 {+ _% j    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
6 b- O! B* b  q9 I! N3 G4 F; J  47740 ceph      20   0   55.4g  55.0g  10356 S   6.6 21.9  11905:23 ceph-mds
& c0 K% P; h5 O( f8 z* s; h1 o0 x" i: m3 b% H: d! u1 `7 p
尝试重启这个mds，直接导致fs瘫痪，mds状态一直都是replay，接着mon好几天都起不来，集群也直接没法用了。。。3 l& z% Z" H* K, Q
: T8 W6 W4 ?9 H1 M
2021-06-17 10:10:36.352 7f9039544700  1 heartbeat_map is_healthy 'Monitor::cpu_tp thread 0x7f9034ccc700' had timed out after 03 [" Y- ]8 i2 `+ Z

% v7 d0 y+ P# R1 ]; y. i6 Qperf top -p 3563473
! e3 }% O0 o  [. j; u% PSamples: 63K of event 'cycles:ppp', Event count (approx.): 49402841395& u. g+ O" {9 P5 A) t; s* ~$ `0 f# f
Overhead  Shared Object         Symbol7 m& K5 B2 p( b; x
  48.92%  libceph-common.so.0   [.] crush_hash32_36 Z0 f. i/ g; ~' M' H' E
  24.28%  libceph-common.so.0   [.] 0x0000000000647f801 P: H9 ?* S' c
   4.35%  libceph-common.so.0   [.] 0x0000000000647f599 |% d7 ]4 p9 b
0 P) L5 @( z/ n
第二次测试，写入一段时间后，集群报错，mds处于rejoin状态3 i# `  H% s# {! Y
4 k% f8 s4 e, k2 k4 H  J
  cluster:
) X8 K- v/ `( y( Z1 T    id:     8418d616-979b-46f9-ab95-b8fb20093d1b, y9 C7 P  f! g% s
    health: HEALTH_WARN& b) g# X' U, N# f. _
            1 filesystem is degraded# U: w: W( d9 g9 y  o
            1 MDSs report oversized cache1 U7 `# J- t6 A9 M" `
            1 MDSs report slow metadata IOs' q6 D, b2 V# Q* U1 E0 w* m
+------+--------+----------------------+----------+-------+-------+! _* }, J: G+ \5 I% l
| Rank | State  |         MDS          | Activity |  dns  |  inos |
/ [  X1 N; h! \& I# e9 Q+------+--------+----------------------+----------+-------+-------+
' c6 W* ^; q5 ]5 C! K  G, C|  0   | rejoin |R03-MTEST-MN-001.xx.cn|          | 59.5M | 59.5M |
) a4 s, L  H3 ~! c  h+------+--------+----------------------+----------+-------+-------+- `3 d: A" e! G) s8 c
* c; K; t7 f: q+ Z
此时mds的内存消耗非常大
( M4 Q5 ^# s% R
. y2 E; {9 B4 ^6 ]- m    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
0 E1 `7 b. y; O7 F! Q; X" V5 L 150540 ceph      20   0  224.9g 223.5g  11704 S 100.0 89.0 196:15.69 ceph-mds
! k1 d: w  q' q
9 j. u$ t+ v$ G/ |, E  P使用命令ceph daemon run/ceph/ceph-mds.R03-MTEST-MN-001.xx.cn.asok flush journal
! C. Y6 c9 z' V% g, q后，降低了一些，但很快又上到了223G
. @  |; S: H! H  R; L" `% V# x; \/ e! e5 J) K& O$ J2 O
从结果上看，该版本的mds主要是没有解决内存的问题，没写多少文件，内存就直线飙升，而且居高不下，妄想重启mds，那就直接玩完9 I% M8 ]$ R9 `' g* p3 [

6 @% F2 X: d7 |0 ?% U这里直接给出13.2.10的建议：不行！事实上，14.2.x之前的版本都不建议使用cephfs上生产环境
3 [- Y" s. b( p2 Z; ]. x
# p1 \+ [. B, ?  }( d14版本的表现
0 D! Q  B  I1 v3 s9 q0 Y) a$ Y在这个版本的测试用，我加入了额外的data pool，并使用了多活mds，直接测试的小文件写入
3 L$ _! [4 k  K+ p8 l: r* A, P: ]0 D, K2 E4 O. M
[twj@R03-MTEST-MN-001.xx.cn test-cephfs]$ sudo ceph fs status
% D) m+ r/ [" d0 m% rcephfs - 40 clients. C2 F: |' L) L& _  w, B( s# X
======
1 y) [0 B- n8 W. M" e# E2 h+------+--------+------------------------+---------------+-------+-------+" u# G) z  `- A& D6 F- s3 Z. B( r
| Rank | State  |          MDS           |    Activity   |  dns  |  inos |
) P% g' _. i7 k# P( i( Y+------+--------+------------------------+---------------+-------+-------+% w0 e" x$ l) C) a2 g) O
|  0   | active | R03-MTEST-MN-003.xx.cn | Reqs: 10.3k/s |  391k |  391k |3 W9 t% A1 c/ }- R9 v3 S4 r
|  1   | active | R03-MTEST-MN-002.xx.cn | Reqs: 10.5k/s |  385k |  385k |4 o- a# |8 m2 V' o; P% |6 N
+------+--------+------------------------+---------------+-------+-------+
& ?+ E& v6 B9 W' ], T+----------------------+----------+-------+-------+4 Z8 w. v" a" ~% U
|         Pool         |   type   |  used | avail |
# @% f# d" {* Y$ A1 w+----------------------+----------+-------+-------+
8 q) R. o. E6 ~+ S0 U) h| cephfs.metadata.pool | metadata | 3378M |  797G |/ S+ {4 U4 {' h; ?
|  cephfs.data.pool1   |   data   | 6085G | 1234T |
# h  }, A" O4 L. a7 Q|  cephfs.data.pool2   |   data   | 2257G | 1241T |" \, G) E1 A* e
+----------------------+----------+-------+-------+. `/ I& d1 C5 b4 [$ v$ P0 R  N
+------------------------+1 j  m2 Q! L- L% w- l
|      Standby MDS       |3 m# X/ }0 V4 K5 l5 M
+------------------------+  Q* [% ?- _8 ?
| R03-MTEST-MN-001.xx.cn |
4 ~/ y0 `; w9 C: p. L8 q, T0 j/ ]+------------------------+
. t/ L% o7 C) ?8 |" U8 k6 YMDS version: ceph version 14.2.20 (36274af6eb7f2a5055f2d53ad448f2694e9046a0) nautilus (stable)
( s% b4 L8 q7 F0 [, i5 C2 _: {4 C
" N2 ~1 Z6 ?+ `! u! c) u: B' h& T其中每个data pool都创建了20个目录，并pin到不同的mds上，性能看还算均衡，连续快速写入，会有告警2 MDSs behind on trimming
- i$ x8 s, h) k# t# k' w8 W4 z但没有什么影响，就没管
" H$ ~9 e- e8 L# [- p
' D$ w8 L0 D2 {. r- i2 @6 U随着数据的大量写入，集群开始出现slow! ^0 Q! s1 [  H1 J% K

, i- ?) Z" P; N& N, @' Z[twj@R03-MTEST-MN-001.xx.cn ~]$ sudo ceph df1 u6 u: \; z0 _5 W
RAW STORAGE:1 X5 G, r* c( ~8 _; F# W* ~
    CLASS     SIZE        AVAIL       USED        RAW USED     %RAW USED8 M! \- }. G" l9 F4 B& ^
    hdd       3.9 PiB     3.1 PiB     823 TiB      823 TiB         20.791 a0 S0 ^/ b' K/ V* w) C' i
    ssd        16 TiB     3.0 TiB      13 TiB       13 TiB         80.72
" O& S6 ]1 C5 Q  u# W    TOTAL     3.9 PiB     3.1 PiB     835 TiB      836 TiB         21.03, s9 H3 ^) O7 z- [
* d+ ^+ s3 H9 _5 P  E" Q) ?
POOLS:. e; I7 I' F0 V
    POOL                     ID     PGS      twjD      OBJECTS     USED        %USED     MAX AVAIL
. k0 m) {" v) M5 e) j% a    cephfs.data.pool1         2     8192     275 TiB     217.81M     413 TiB     23.20       911 TiB$ |! V' O# \9 P( @6 M0 c
    cephfs.data.pool2         3     8192     244 TiB     102.44M     366 TiB     20.53       946 TiB
( t: V# |( r2 H4 ]3 k; [    cephfs.metadata.pool      4      256     127 GiB     115.39k     191 GiB      7.74       760 GiB
" r- L2 q0 [. Y) O    " F0 J7 U3 H8 `
[twj@R03-MTEST-MN-001.xx.cn ~]$ sudo ceph health detail
) _- [+ A/ ?( w  [HEALTH_WARN 1 MDSs report slow metadata IOs; 1 MDSs report slow requests8 L% W+ W, b( c: w+ J
MDS_SLOW_METADATA_IO 1 MDSs report slow metadata IOs- |/ z; E! j" D# ~. ]
    mds.R03-MTEST-MN-002.xx.cn(mds.1): 100+ slow metadata IOs are blocked > 30 secs, oldest blocked for 87 secs3 W$ O* d& t: H; d4 h
MDS_SLOW_REQUEST 1 MDSs report slow requests
: o# U0 H5 g. w% G. u6 J6 z    mds.R03-MTEST-MN-002.xx.cn(mds.1): 11 slow requests are blocked > 30 secs
% L7 I! V' r3 P0 @- L  B2 }: \  y# D& J" `/ s
查看mds的op处理流程' i2 g2 D# X5 Y8 [
3 ?9 j6 `  m- x7 {6 y6 W
[twj@R03-MTEST-MN-002.xx.cn ~]$ sudo ceph daemon mds.`hostname` dump_historic_ops_by_duration|grep duration* }& l+ W9 b9 z' D: D4 P7 e' i
    "duration": 600,
" o6 I. e! U- Y" E" ]5 W3 x            "duration": 427.63886984499999,- d2 ]/ h( ?3 K- C( C
            "duration": 427.62001601499998,
  J# i; V2 q# R9 ^            "duration": 409.772382456,
$ v, b6 i- A" _/ l3 j( s+ A8 ]5 O            "duration": 409.75990740399999,
( J! U: F2 D+ X. ]6 H            "duration": 215.47288510800001,' q& Y% w" t; r; |- n& {
            "duration": 214.47418489699999,# L# Y" d0 h* F. R
            "duration": 203.97045117499999,
9 j) n; I6 z8 {. f            "duration": 203.51505527899999,
- D4 g+ m) C' q) E3 d# i& ~# P            ...
. v+ `7 {, I) P9 ^9 [. ^5 T6 j& q! Q0 M2 t  l, n5 e
时间都非常久，继续排查，发现大量的op都是卡在failed to rdlock, waiting
3 w# x4 S) z  Z6 Y# h这个步骤，关于这种情况的调查和优化，还在努力。。。
7 J* L& q0 W$ k5 M4 g% G( f  E* ]; K; U& _# Q4 ~
看了一眼内存，没有明显的飙升  u6 ^2 e8 X9 o
" ]: N% o4 h1 K- V" x
[twj@R03-MTEST-MN-003.xx.cn ~]$ top) n, r  C# G* y9 V# G. }" x
top - 15:34:57 up 9 days,  4:36,  1 user,  load average: 0.95, 1.22, 1.28
# o3 y  \9 ^) Z  C- j5 DTasks: 650 total,   1 running, 649 sleeping,   0 stopped,   0 zombie5 @+ ]! l9 R& v0 R: D; X/ b
%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- G' v- a" q; H
KiB Mem : 26353089+total, 25013656+free, 11907872 used,  1486464 buff/cache
% w' u+ f$ l8 F# lKiB Swap: 16777212 total, 16777212 free,        0 used. 24535932+avail Mem
) f4 x, C" u0 ?
5 a  O2 y- Y! W) K6 x  d3 Q    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND7 B* w9 Q- H. d) A% j8 `# f+ T
  29657 ceph      20   0 7878864   2.5g  14288 S 100.7  1.0   4616:55 ceph-mds
7 ?; c1 W6 G: o: i% b% d: O4 Q6 ~& i+ g1 r- i
大量数据写入后，先测试一下mds的重启，直接reboot节点，观察集群的情况6 v/ L; m& R$ X5 w2 C

) p( e# |3 ~9 N6 q[twj@R03-MTEST-MN-002.xx.cn ~]$ sudo ceph fs status
0 w+ @5 m% E4 o1 ycephfs - 40 clients3 T' I0 F- B. C: [* A
======6 T: x, @7 E6 x8 C5 K" K4 T
+------+--------+------------------------+---------------+-------+-------+3 x7 x% D/ V1 n$ U
| Rank | State  |          MDS           |    Activity   |  dns  |  inos |+ n: y! u9 b7 p( q2 |9 o0 F
+------+--------+------------------------+---------------+-------+-------+' p; Z* M% W$ N
|  0   | active | R03-MTEST-MN-001.xx.cn | Reqs:  869 s |  445k |  445k |
* P0 x  n' C  X3 d$ W8 ]|  1   | active | R03-MTEST-MN-002.xx.cn | Reqs:    0 s |  365k |  365k |* }, q! @+ D! D, t& I- G4 B- `: j: ?
+------+--------+------------------------+---------------+-------+-------+1 n/ m1 S4 E" L( [
+----------------------+----------+-------+-------+7 [; C3 T5 N5 `% j: @' A
|         Pool         |   type   |  used | avail |
9 \6 \9 S5 h4 Q2 Z. L$ F/ v* w+----------------------+----------+-------+-------+/ o& P- e# e# F9 o, {
| cephfs.metadata.pool | metadata |  186G |  762G |
) a% T, u. i: v. m8 q6 m$ @|  cephfs.data.pool1   |   data   |  412T |  910T |$ T* F* d. t+ d4 }' u
|  cephfs.data.pool2   |   data   |  366T |  945T |! F; M# b; R, r2 ?1 y. _
+----------------------+----------+-------+-------+
5 Z$ T' d! }# h2 B/ O+------------------------+( z. ^& Z! L& k( G# Q- V
|      Standby MDS       |
- X: D0 F8 u0 u$ @. T/ p+------------------------+
* F: }. U8 a! ]  k( Z6 m" I| R03-MTEST-MN-003.xx.cn |6 c# \" U2 d% K& s  _: [
+------------------------+  M. H  C3 Q# Y  v1 G
MDS version: ceph version 14.2.20 (36274af6eb7f2a5055f2d53ad448f2694e9046a0) nautilus (stable)! O+ V, Q9 Z; f( @7 I$ B! C1 q
0 E; V% `  M7 Z8 W  ^
看是备是直接顶上了，mds重启后自动做备，业务侧暂时没有发现有问题，不过，发现写入的流量都打到了同一个mds，不知道是不是因为rank序号变化导致的; l" k! ^" N5 O7 r8 b
$ F* ]- Z2 H$ Q3 j0 J1 ~* M
测试发现，当单个目录对象数达到千万级时，cephfs的目录出现明显的卡顿，测试读，读取偶尔会有问题，流量不稳定，最大可到1GiB/s，最小只有几百M
) ]- F0 L, `1 y3 K0 m' k, p, s$ w
  io:
1 |% x& w/ N0 g* V" y% c( o    client:   240 MiB/s rd, 559 KiB/s wr, 102 op/s rd, 0 op/s wr
, D' m) `3 D) q2 Z! Z# x  ^' O' Y; q4 y
结论1 E& @6 F5 s# e: P! m" I, q
cephfs 14.2.20测试结果来看，稳定性可靠性还是可以的，至少内存的问题看来是解决了，没有出现持续大量数据写入时产生的高内存占用问题，同时，重启其中一个rank，备用的mds会自动顶上，业务没有太大影响，而且，目录内的文件数量只要不是太大，小于百万级的话，性能也没有太大的问题，因此，14.2.20及后续版本的cephfs应该是可以上生产的了) d5 a$ E6 t- |
1 c( j* @4 q# I: x' o, @0 h8 A
反观此前的版本，12、13都比较拉垮，mds不太靠谱，如果client有故障，读写卡住，mds分分钟给你瘫痪，极具危险性，还是不建议上，如果已经有在线的fs，还是强烈建议迁移到14.2.20+的版本5 C; o% O2 l8 D* f
& ?, O6 t/ L; S- H8 H
下一步，将继续测试cephfs的其他异常情况和大规模数据写入后slow req的问题，并对代码逻辑方面进行一些分析，敬请期待^_^) u) k2 X/ P6 l3 m0 L9 k  n

9 R4 g$ H  Y/ D/ f) u
回复

举报

admin

0

主题

0

回帖

9

积分

管理员

积分
9
QQ
 楼主| 发表于 2023-2-3 21:14:28 | 显示全部楼层
一、pg相关#) g4 v5 {4 d2 c& @5 Z4 ~
1、xx objects unfound#
* ]( k0 K" P3 I- M! ^" y- 问题描述：#2 t! O5 x7 l2 @. u7 X
dmesg查看磁盘发现读写异常，部分对象损坏（处于objects nofound状态），集群处于ERR状态2 }/ q. g% V& t, r  K7 P1 N

& C: u4 }8 @  x( Oroot@node1101:~# ceph health detail; D" e/ q9 _1 G) W
HEALTH_ERR noscrub,nodeep-scrub flag(s) set; 13/409798 objects unfound(0.003%)；17 stuck requests are blocked > 4096 sec. Implicated osds 382 W5 j% X2 e: q; O" C! W0 Q. m
OSDMAP_FLAGS noscrub,nodeep-scrub flag(s) set: v3 C0 `7 ^/ K1 ~
OBJECT_UNFOUND 13/409798 objects unfound (0.003%)
0 i* b/ P) K* \8 B  S' k  pg 5.309 has 1 unfound objects
$ u- `' n+ c( L, W  pg 5.2da has 1 unfound objects) k7 K8 `5 @* b# M1 I
  pg 5.2c9 has 1 unfound objects3 r' r  B  `  e) Q' {$ o/ J
  pg 5.1e2 has 1 unfound objects
7 I0 C2 ~) M2 f; M, |6 a  pg 5.6a has 1 unfound objects
" u! W8 G, m  |/ G9 _  pg 5.120 has 1 unfound objects
0 u: [4 l/ U8 \! L  pg 5.148 has 1 unfound objects! {/ g/ Z) ^1 d/ X
  pg 5.14b has 1 unfound objects& p, U* f( _/ g' t; m; k
  pg 5.160 has 1 unfound objects
( g  Z" X7 G! Z& }/ ]  pg 5.35b has 1 unfound objects
( x1 B: _6 s- q% p/ v7 V  pg 5.39c has 1 unfound objects3 n, _5 T* y4 U% |! G3 j
  pg 5.3ad has 1 unfound objects
/ ?) ?! z, P3 p; [: BREQUEST_STUCK 17 stuck requests are blocked > 4096 sec. Implicated osds 38" a& {/ f3 }# _0 Z4 }$ ^3 g; ?& ?
  17 ops are blocked > 67108.9 sec; ?1 o$ L# l+ |( Y( b
  osd.38 has stuck requests > 67108.9 sec6 ]7 e- `6 `/ m, d( o8 a
- 处理措施：#
0 R9 w  G) K0 A& |将unfound pg强制删除，参考命令：ceph pg {pgid} mark_unfound_lost delete" f1 M% x" O) k1 e! L6 O" M
注：如需批量删除unfound pg，则参考命令如下
' z, V, z/ z1 s, ~6 ^3 u
5 [7 D+ @/ q1 L/ rfor i in `ceph health detail | grep pg | awk '{print $2}'`;do ceph pg $i mark_unfound_lost delete;done, b; c3 X& E4 o8 E7 _. n9 v8 E
2、Reduced data availability: xx pgs inactive#
( M( K3 [; M# Q+ |- 问题描述：#
  G7 Q' }- ~, ^磁盘出现读写异常，osd无法启动，强制替换故障盘为新盘加入到集群，出现pgs inactive（unkown）
, l* s& R' P8 u
$ X0 h4 M4 X2 W/ I  h6 ?root@node1106:~# ceph -s+ ?9 ~- u. n. b, b( H7 q) C1 y( R
  cluster:
2 c( f% ]5 {) Q    id:     7f1aa879-afbb-4b19-9bc3-8f55c8ecbbb4
; U  ~$ ?( H1 F  x    health: HEALTH_WARN
$ ]- b) ?; v% d            4 clients failing to respond to capability release
; A$ h- r+ E" X( D; j. W            3 MDSs report slow metadata IOs: Y$ \( h' S# M0 S
            1 MDSs report slow requests6 f5 R. G7 ~7 n( N* k
            3 MDSs behind on trimming* T# s) O; _: N
            noscrub,nodeep-scrub flag(s) set- ~- y% }' y) G. ?
            Reduced data availability: 25 pgs inactive7 Z  ]3 s4 r6 e  b% [. @9 a
            6187 slow requests are blocked > 32 sec. Implicated osds 41
6 f# s5 C/ S5 L/ V; p. C/ }+ L5 Q' i# c8 u  D
5 n0 Q, ~6 D4 ?7 h, l) U. B) t/ G
  services:
3 a2 K8 T& }+ I8 m" \3 J    mon: 3 daemons, quorum node1101,node1102,node1103
7 F! w! I* X, W/ D- L2 ]/ `    mgr: node1103(active), standbys: node1102, node1101
+ o" m, u1 Y6 `    mds: ceph-3/3/3 up  {0=node1103=up:active,1=node1102=up:active,2=node1104=up:active}, 2 up:standby
$ O- z' L) ]0 u+ W( D* A  p( _7 S    osd: 48 osds: 48 up, 48 in
* H3 V: K4 Q- E: V         flags noscrub,nodeep-scrub+ v3 U5 N3 [( T& a

7 }: L! x1 p( P/ h/ B! w  M/ r
' H5 j- a( \) T% M+ @" g1 W  data:
" V) L8 H7 F& G    pools:   6 pools, 2888 pgs, Z: I: {" U! e* [. j
    objects: 474.95k objects, 94.5GiB' O& }  o& r. L3 k. a/ J8 c4 v
    usage:   267GiB used, 202TiB / 202TiB avail
. N; Q2 q3 a8 C6 Z  D    pgs:     0.866% pgs unknown
, M; B4 {$ A4 Q: s5 n( D             2863 active+clean
5 [( N2 D1 t  l* ?+ p4 G3 P8 x             25   unknown4 @/ v' g8 f- r5 b% C( S

# E% u# Y% ~. c. i, B
! K& _2 g" y# ~root@node1101:~# ceph pg dump_stuck inactive
; H4 z/ n. u* E; o7 `! \ok
! j2 ?4 T( j' |& A1 K" S. n* x' CPG_STAT STATE   UP UP_PRIMARY ACTING ACTING_PRIMARY 2 E$ W( \% q- M( W' q1 N
1.166   unknown []         -1     []             -1 " d$ ?* ]/ t2 r+ v+ `9 F
1.163   unknown []         -1     []             -1 , F6 P" c8 |* r  P. P/ C
1.26f   unknown []         -1     []             -1 : D7 b  h& S' B" n6 \" M9 z# k
1.228   unknown []         -1     []             -1 % M! g+ X! m. G- d8 t, X
1.213   unknown []         -1     []             -1
7 H( l  a: a* z$ N7 Z1 u  R1.12f   unknown []         -1     []             -1 ) u' j. h, d4 i6 H$ l+ ]4 p2 P
1.276   unknown []         -1     []             -1 & Q* ~/ O. L+ m! W
1.264   unknown []         -1     []             -1
/ C9 `; A' H# F6 r# r( E3 r( Z1.32a   unknown []         -1     []             -1 , \* C% \. ]3 k6 }6 u- h: Q
1.151   unknown []         -1     []             -1 1 ?4 @( r& t0 K# h9 J. k" F
1.20d   unknown []         -1     []             -1
) H5 L4 I) A1 G7 x7 o0 |1.298   unknown []         -1     []             -1
# P& j; M$ j8 F4 `% r$ K1.306   unknown []         -1     []             -1
6 V1 @$ _4 ?$ R: E3 b' v1.2f7   unknown []         -1     []             -1 % D/ k& s% m+ Z# E( N
1.2c8   unknown []         -1     []             -1   T- c) k+ U6 i& [
1.223   unknown []         -1     []             -1
- M: O6 S  b+ j& ?' t! g) {1 g& V1.204   unknown []         -1     []             -1 8 a# _/ [) |+ y, Y
1.374   unknown []         -1     []             -1
+ a  l% W) d6 T6 r3 n0 i, n1.b5    unknown []         -1     []             -1 " c3 {7 l7 Y; `9 t
1.b6    unknown []         -1     []             -1 , U" k" T4 w& ]- E" L9 s: k
1.2b    unknown []         -1     []             -1
4 w9 C) D( v2 |! F% g3 f1.9f    unknown []         -1     []             -1
5 f8 q2 @! E2 a2 |1.2ac   unknown []         -1     []             -1 7 o0 H' T( b* m* z0 m* x, Q
1.78    unknown []         -1     []             -1 6 S( r3 K0 d! G( X  d0 P! W
1.1c3   unknown []         -1     []             -1 5 {- E' O/ E( U# u
1.1a    unknown []         -1     []             -1 7 Z! |: j7 a/ t$ i- B; |; c
1.d9    unknown []         -1     []             -1
5 |* f: S; F3 ^: R) v2 a: y; b; q- 处理措施：#
* |* }6 r# ]% o6 Q' z( t强制创建unkown pg，参考命令：ceph osd force-create-pg {pgid}0 H4 u8 ^! h( G) D7 G" s
注：如需批量创建unkown pg，则参考命令如下：3 o# \( {5 _8 P+ X# v9 V* q6 R2 z1 \

3 u" n7 i* b$ k( s; Vfor i in `ceph pg dump_stuck inactive | awk '{if (NR>2){print $1}}'`;do ceph osd force-create-pg $i;done0 x6 Q% ~9 k; |, U
二、OSD相关#0 N0 d- C) B$ }& Z3 g/ a
1、osd端口与其他服务固定绑定端口冲突#: T! N; r* k: Z) K8 p5 M% y( V
- 问题描述：#
2 D: t1 ?" P% V3 u( w+ \9 Vosd先行启动，占用其他服务固定绑定端口，导致其他服务绑定端口失败，无法启动
" u+ P8 {, m, A3 L
2 T( N: a1 h. u( o1 g- 处理措施：#+ ~  v9 p- W  [: L3 j
考虑到其他服务涉及组件太多，担心修改不完全导致其他问题发生，尝试修改osd启动端口范围为其他服务之外
$ B( K: ^7 M' U( ]% ^, Z6 }0 I" e5 F5 L
修改osd作为服务端的启动端口范围9 S" z  z% t. r7 N+ U7 W" j
ceph可通过ms_bind_port_min和ms_bind_port_max参数限制osd和mds守护进程使用端口范围，默认范围为6800：7300$ A& c9 ?0 G' C2 f/ y" E3 w1 o
设置端口使用范围为9600:10000，追加参数设置至/etc/ceph/ceph.conf文件中[global]字段内
8 W1 Q" A/ x# y6 I) t6 {2 R* j. k7 L* m  P[root@node111 ~]# cat /etc/ceph/ceph.conf | grep ms_bind_port
  k$ O, j' q* Z; i$ X! Zms_bind_port_min = 96008 |3 t" u" z# ^: C
ms_bind_port_max = 100001 X8 z6 E0 V4 P1 m" W0 o% E
[root@node111 ~]#
# c5 |; `! S( F& z[root@node111 ~]# ceph --show-config | grep ms_bind_port2 B5 |, N$ o7 t
ms_bind_port_max = 10000" `6 x# s8 e& l0 O! j
ms_bind_port_min = 9600
) ^( v2 p+ P2 b% j& v修改osd作为客户端的启动端口范围% Y5 z* v+ h% c
osd作为客户端的启动端口为随机分配的，可通过内核去限制随机端口分配范围
( _9 L# t# }2 I8 u) O* X% J& e默认端口范围为1024：65000，修改端口范围为7500：65000
) P$ _8 S* L6 H' q--默认端口范围为1024：65000
" L- l# I2 `" x$ Z/ R5 U8 x[root@node111 ~]# cat /proc/sys/net/ipv4/ip_local_port_range " ~/ C% ]6 v, l+ Y+ q
1024    65000
4 A8 H8 Y7 d/ s9 d$ G" Q--修改范围为7500：65000
4 i$ Y1 [- Y9 _% h4 K; h' u& m  `[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 ; z( M4 U/ P, V. W* [
[root@node111 ~]# sysctl -p
/ K# g8 p8 n2 ^2、磁盘热插拔，osd无法上线#
% B- L2 Q8 Q: D9 u7 M8 s/ n2 N- 问题描述：#  H- c. J+ {: ~6 A5 t, `
使用bluestore部署ceph集群，对osd所在磁盘进行热插拔操作，当重新插回之后，osd对应lvm不能自动恢复，导致osd无法上线成功1 L2 X3 g  F! E3 K8 G. d

) k5 V. G1 W. Q% F7 O; w$ u- B  m
: }. |8 d7 I! E; Z9 u0 A# @4 W7 L8 C, @5 ~
- 处理措施：#, C( `! `  z* m- B
查找故障osd对应uuid：
1 B/ b. U0 T4 T: }( G6 L5 h9 T# cceph osd dump | grep {osd-id} | awk '{print $NF}'7 i6 G2 F7 `8 v) L
参考示例：查找osd.0对应uuid
/ R  e7 g9 f2 a0 T3 g[root@node127 ~]# ceph osd dump | grep osd.0 | awk '{print $NF}'* P* x9 v/ M7 u( z0 N: O4 R; n
57377809-fba4-4389-8703-f9603f16e60d3 V. O( v: R' `
查找故障osd对应lvm路径：1 h: `% s- \6 A
ls /dev/mapper/ | grep `ceph osd dump | grep {osd-id} | awk '{print $NF}' | sed 's/-/--/g'`, B& Q3 T( ?4 Y: j! p/ _
参考示例：通过uuid查找对应lvm路径
0 |3 b5 k- ~4 d" {注：由于lvm路径对uuid做了处理，需要sed 's/-/--/g'`将-替换为--# }+ O% n, Q9 A: @
[root@node127 ~]# ls /dev/mapper/ | grep `ceph osd dump | grep osd.0 | awk '{print $NF}' | sed 's/-/--/g'`
& g* @& @: y& W2 W# g* @ceph--3182c42e--f8d8--4c13--ad92--987463d626c8-osd--block--57377809--fba4--4389--8703--f9603f16e60d) O/ W- P2 @" r0 k3 }
删除故障osd对应lvm路径+ F4 D: G' q/ \* e
dmsetup remove /dev/mapper/{lvm-path}+ i+ O: H# X' |1 z& K7 L/ s- z1 j
参考示例：删除故障osd对应lvm路径
) D% g# d' E: w: Y[root@node127 ~]# dmsetup remove /dev/mapper/ceph--3182c42e--f8d8--4c13--ad92--987463d626c8-osd--block--57377809--fba4--4389--8703--f9603f16e60d ' Q' M' _) O# A% d. [% W: l& h
重新激活所有lvm卷组
" w1 L, N' @( x/ |' E注：此时可以查看到对应故障osd的lvm信息
" D+ o' h9 @/ n8 `( `vgchange -ay) w; T: N. b6 s6 L1 {- o
重新启动osd使得osd上线) `: d3 v$ @8 K* U8 z
systemctl start ceph-volume@lvm-{osd-id}-{osd-uuid}
7 N  W  i' r/ O$ R三、集群相关#! M- m( ^3 c# V4 I) j  O$ f
1、clock skew detected on mon.node2#4 r4 S4 [) Q1 e& e5 e# `
- 问题描述：#
7 l# _  a. J1 H+ i0 F$ R集群mon节点时间偏差过大，出现clock skew detected on mon.node2 告警信息" {+ \; x% ~( E4 V, X- |; C
0 k: m$ ~$ l. b  L, J* R
- 处理措施：#
% i$ y! b* N: s1、检查集群mon节点时间偏差，使用chronyd时间进行集群时间同步+ N6 v* O) y. R4 R; p
2、调大集群参数阈值，调整mon_clock_drift_allowed 参数值为2，调整mon_clock_drift_warn_backoff 参数值为30% k" `9 ]8 p5 M7 k# c7 w7 o* y
0 |1 c. d6 q/ d1 X$ z/ n3 j$ v6 q
sed -i "2 amon_clock_drift_allowed = 2" /etc/ceph/ceph.conf
  S& o1 h" p3 F* D) Z0 U$ X4 {sed -i "3 amon_clock_drift_warn_backoff = 30" /etc/ceph/ceph.conf% o; O( s* e1 p  X# S8 j
ceph tell mon.* injectargs '--mon_clock_drift_allowed 2'9 _! U7 g* v: Z8 g# \9 s5 O- [
ceph tell mon.* injectargs '--mon_clock_drift_warn_backoff 30'
+ t8 r& C  A) g  ^) q1 b& z注：相关参数说明如下：& R% f. G0 F5 s) E# a

7 d, R0 V5 m! f+ P6 `& E! Z4 P[root@node147 ~]# ceph --show-config | grep mon_clock_drift. F/ J7 o- l' U9 c, u& y& s
mon_clock_drift_allowed = 0.050000: ^( j% j: N2 o+ y( b9 H5 z
--当mon节点之间时间偏移超过0.05秒，则不正常( c- l3 a6 J: \" O8 f4 g
mon_clock_drift_warn_backoff = 5.000000" k" ~4 a/ O* m+ ~# T* H# Y
--当出现5次偏移，则上报告警
回复

举报

返回列表 发新帖
高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 注册

本版积分规则

返回首页|Archiver|手机版|小黑屋|易陆发现技术论坛 ( 蜀ICP备2026014127号-1 )

GMT+8, 2026-6-11 22:58 , Processed in 0.026981 second(s), 23 queries .

Powered by Discuz! X5.0

© 2001-2026 Discuz! Team.

快速回复 返回顶部 返回列表