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

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

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

[复制链接]
admin

1

主题

0

回帖

12

积分

管理员

积分
12
QQ
发表于 2023-2-3 11:13:00 | 显示全部楼层 |阅读模式
[root@8-5 ~]# ceph health detail
3 r1 P  a5 u/ D- H" V7 cHEALTH_WARN 1 MDSs report slow metadata IOs; 1 MDSs report slow requests
9 J" y; Y3 A: e* P8 q[WRN] MDS_SLOW_METADATA_IO: 1 MDSs report slow metadata IOs( U4 P2 a( z# J2 B% v& B  |2 F
    mds.cephfs.gm268-2.xdsdoz(mds.0): 100+ slow metadata IOs are blocked > 30 secs, oldest blocked for 2718 secs9 _2 L0 V. [7 n6 ~
[WRN] MDS_SLOW_REQUEST: 1 MDSs report slow requests$ ?1 z/ t: {* a1 S. q
    mds.cephfs.gm268-2.xdsdoz(mds.0): 73 slow requests are blocked > 30 secs
  N, ~7 ], N( r( @, c
1 i& o, ]0 s1 f7 I/ G" S6 B% J5 A5 K) e8 ~# a8 n
出现这种提示会导致集群对请求没有反应，解决办法就是重启所有的ceph节点即可：) v! o$ b4 W3 q9 [5 t) o# v
systemctl restart ceph.target或者重启服务器也可解决问题，响应慢可以使用重启的方式来重新发起集群数据均衡。& i: K" i$ r. ?: L7 |, a
' F" A1 V) C* N. i5 G- V
观察结果
9 p8 H- v% G4 G& q! J
4 H. B2 Q6 t2 @4 e0 g3 o
. |5 W. _2 g6 H. k" g1 W( t3 T- @1 ^" w- q% `5 r
1 H, i0 I' t' a8 c& G
1. Slow OSD heartbeats
  • # ceph -s
  • health: HEALTH_WARN
  •        Slow OSD heartbeats on back (longest 6181.010ms)
  •        Slow OSD heartbeats on front (longest 5953.232ms)1 R5 y* ?, V7 x1 W. O: X, c
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延迟都比较高，将该主机的光纤网线拔下擦拭干净并重新插上得以解决。7 X3 f  A, u/ n, T9 s' a1 R5 p+ S
2. slow ops
  • # ceph -s
  •      21 slow ops, oldest one blocked for 29972 sec, mon.ceph1 has slow ops+ a+ {2 X& B" ?8 h. h( [
先保证所有存储服务器上的时间同步一致，再重启相应主机上的moniter服务解决。
3. pgs not deep-scrubbed in time
  • # ceph -s
  •     47 pgs not deep-scrubbed in time
    3 z+ d7 F; H4 f
应该是OSDs掉线后，CEPH自动进行数据恢复。再将相应的OSDs重新加入后，则需要将恢复的数据再擦除掉。于是提示相应的警告信息，正在进行删除相关的操作，且其pgs的数量会不断变少。等待一段时间后，则恢复正常，此时ceph文件系统性能很差。
4. MDS cache is too large
  • ceph config set mds mds_cache_memory_limit 10GB
  • ceph config dump! u1 `3 ~5 z6 ?$ g
当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; `+ v& [, y/ {8 B0 s
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
    4 u: k, K; ]7 x$ B' j& \
谨慎使用如下命令踢出目标客户端或全部客户端。
  • ceph tell mds.0 session evict id=11134635
  • ceph tell mds.0 session evict# e8 |% A3 P* A6 Z$ Y) C
踢出客户端是将客户端加入了黑名单，可以使用如下命令查看黑名单信息或移出黑名单。虽然移出黑名单，可能还不能让客户端正常挂载ceph文件系统，因此需要谨慎处理。
  • ceph osd blacklist ls
  • ceph osd blacklist rm 192.168.20.1:0/1498586492
  • ceph osd blacklist clear- o: K6 J1 t* r/ ^/ E0 M
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')
    + ?8 N/ Q0 K) D; w! S# W
此时，需要修复pgs。
  • # 查询pg信息（pg id 为 5.6de）
  • ceph pg 5.6de query
  • # 强行重建pg
  • ceph osd force-create-pg 5.6de --yes-i-really-mean-it' w! {: ^9 p3 F+ i8 P4 a& T3 u7 U3 y
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$ P$ X9 C( k# ^+ U5 s0 K/ t
执行以下命令时，会有如上报错。而正常的存储节点则不会报错。
  • cephadm shell
    % S5 ^  Z4 w( M
该类报错表示podman的docker容器出错。查找出错的存储节点：
  • ceph orch ps | grep error7 ~) W. N3 h, z7 |# S" j) L
在各存储节点重新pull相应的docker镜像：
  • cephadm pull
  • podman pull ceph/ceph:v15
  • # 以上两个命令都可以达到目的，后者能看到下载的速度，以免等待较长时间下载几百M的文件而不清楚进度。
  • # 重新pull镜像后，会提升ceph版本。不会影响使用9 G% V$ O, ~) V
检查podman的docker镜像
  • podman images
  • podman ps" M/ H; O" m2 Z- t9 w, D- t/ k
最后重启服务器或重启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
    , Q9 K( C$ P7 c! `7 z# f
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
    3 O6 N  m  e9 V# v% }5 ^0 Z+ ]# \
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: D. U9 |9 w7 f  j$ |& R% ?
以上报警表示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
    8 T4 t1 [( `. D' g) h# l

7 z: z" u' |; a. z
4 u5 z7 l6 d, u+ y# B/ @3 s
( o  v& s+ F" s0 O* A# N% |
回复

举报

admin

1

主题

0

回帖

12

积分

管理员

积分
12
QQ
 楼主| 发表于 2023-2-3 17:26:18 | 显示全部楼层
开始
, F' w7 r. z  q8 C6 T6 n  Z& M1 m此前，博客有更新一篇关于cephfs的文章 - 小试牛刀，主要是cephfs的一些基本的使用，版本也是比较早期的12版本, p! _4 r1 u8 l1 O

& ]3 ?1 X* y3 j0 V5 b此后不少读者和我探讨过cephfs的情况，我给出的建议一律是：cephfs不建议上生产，不稳定# L' E+ |& V6 }9 j, ]3 B: [+ y+ y

* C. ~9 y1 v  X, o, ]时至今日，cephfs经过了多个版本的迭代开发，据说可以上生产了，这里我们对其进行一些列的测试
2 L8 b, i9 R1 {. i6 I" Q! K7 P9 u( G: \/ o. Q# H" Q0 L; \* f: n$ f4 B
测试是这样，先使用了13.2.10版本进行测试，然后使用14.2.20进行相同的测试，测试环境:9 \# L7 O$ B" u- ^# L  ]% a
8 e, q+ `6 f* ^
data pool 使用ec 4+2
- N9 {  s% x+ U- |3 u9 s  p% `9 O" h
7 s( M, z8 n! k( I- C6 T0 F写入大文件(64GiB)
$ W- O1 B; ^, F4 B/ S& ?8 y
2 U9 c  l8 N1 [! u写入大量较小小文件(4MiB+1MiB)
* P. f! ^  {5 k4 Q4 m+ ~- q) ~1 u. j* ?) r9 `
写满pool后进行纯粹的读取
+ U& y0 B! D! [  V' K. ?  u5 X
写入时重启某个rank+ q" n4 X, H  d& K: ]
2 g0 j3 c5 H$ T) Q
13版本的情况0 a3 m' |8 A: }1 z
写入大文件(64GiB)写满pool，这个没有问题，写满pool也不用多少个文件，读取也顺利
! c( s! L. R: r, _( K1 k
" B- `: Y6 [$ R# Q: U4 ^* K写入大量较小的文件就不行了，读取也不能正常进行& L' C' t- R# A8 P3 H+ x" @6 N

1 [9 i- W8 D& z; A默认配置下，cephfs的根目录下创建10个目录，写入大量的文件2 P/ j! G# `' P& a. B* s1 D

6 q5 h% f. I' F* z[twj@R03-MTEST-DN-017.xx.cn ~]$ sudo ceph fs status5 S  B: k& Y- P, |% Z
filecephfs - 3 clients0 j6 ]5 T4 R( M* b% g' u8 K6 j
==========) W3 t* a: Q8 K8 {" E" @  O) p
+------+--------+------------------------+---------------+-------+-------+, u! }1 C' m0 O
| Rank | State  |          MDS           |    Activity   |  dns  |  inos |: g$ }  o) x# k2 o, V3 d5 e
+------+--------+------------------------+---------------+-------+-------+8 [! B% W! }3 p4 V1 V
|  0   | active | R03-MTEST-MN-002.xx.cn | Reqs:    0 s | 19.8M | 19.8M |9 t8 g; n1 a! N* ], X2 _
+------+--------+------------------------+---------------+-------+-------+
- _1 v0 }0 c, T4 ~% ~* u0 G" F" t+----------------------+----------+-------+-------+1 z9 W2 o& e! f0 h5 D
|         Pool         |   type   |  used | avail |( r% }5 l" p+ R
+----------------------+----------+-------+-------+
' }2 R1 D4 o; g% B; Y4 }7 {| cephfs-metadata-pool | metadata |  155M |  794G |8 Q1 e8 |! \) g# H/ c- \
|   cephfs-data-pool   |   data   |  957T |    0  |
& x+ A# O% c1 j9 o+----------------------+----------+-------+-------+
  A  b/ d! l- `* _0 z5 ~4 o+------------------------+  E7 e5 R6 o; I# g+ Q3 W
|      Standby MDS       |7 u% c' c3 E& m# F/ v- S7 [
+------------------------+) T# q# n0 c6 A) M0 ^) G. i
| R03-MTEST-MN-001.xx.cn |2 m! R  ]& J( Q9 R
+------------------------+& A% x" @, z3 X
MDS version: ceph version 13.2.10 (564bdc4ae87418a232fc901524470e1a0f76d641) mimic (stable)- `) o) S9 D5 u& A
[twj@R03-MTEST-MN-001.xx.cn ~]$ sudo ceph df
. D# c! b5 }3 i. _) f/ ^: p! V( JGLOBAL:
: u/ w  z/ Z& m8 C& I/ K4 f4 g    SIZE        AVAIL      RAW USED     %RAW USED
, g/ |6 W/ Y4 m  W- J% Z0 X( L& k    1.5 PiB     91 TiB      1.4 PiB         94.088 g7 f0 }! _$ D) |+ t
POOLS:: ?/ v& \* j5 v3 P3 O( {- e. y
    NAME                     ID     USED        %USED      MAX AVAIL     OBJECTS
1 @% A. g3 q" p" d    cephfs-data-pool         15     957 TiB     100.00           0 B     561286578% @$ H7 e; n% G: ]( j
    cephfs-metadata-pool     17     155 MiB       0.02       795 GiB         98368% v: [. C! ^- E" }) X% j% y
8 d% ~5 G' L* z1 y( l
此时，mds的内存占用达到了55g! a6 s0 w5 c2 _; L4 V# y! n  c

/ s- g) @  l- _( @# L9 G    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND, c! M2 @% C" Y9 `* |0 y
  47740 ceph      20   0   55.4g  55.0g  10356 S   6.6 21.9  11905:23 ceph-mds/ D3 U0 V' j0 S2 L1 A
% l( V, ?6 L. j  x" i. [4 n4 z  W
尝试重启这个mds，直接导致fs瘫痪，mds状态一直都是replay，接着mon好几天都起不来，集群也直接没法用了。。。
5 {& ?% @; F9 g$ N5 P$ L3 |3 q# V& |0 G- r, l. i/ E
2021-06-17 10:10:36.352 7f9039544700  1 heartbeat_map is_healthy 'Monitor::cpu_tp thread 0x7f9034ccc700' had timed out after 0
( L! q5 K* ^4 B  T1 f
! A7 l) ^: u, _( m. i, @perf top -p 35634735 g- o" }) K4 M1 z
Samples: 63K of event 'cycles:ppp', Event count (approx.): 49402841395
/ x% X- B- i; i5 W0 ~' Y" NOverhead  Shared Object         Symbol
/ c9 F5 O, a, B1 w6 _  48.92%  libceph-common.so.0   [.] crush_hash32_3
0 L. Y, T- X1 c: ?  24.28%  libceph-common.so.0   [.] 0x0000000000647f80
, Y7 Y9 q$ d9 i: `   4.35%  libceph-common.so.0   [.] 0x0000000000647f59
- `" J/ O0 X. x/ E& h8 q
) q2 b' g  K" m* X& Y0 p# w1 j& K第二次测试，写入一段时间后，集群报错，mds处于rejoin状态% d. j2 M, U' @. N  ]6 v

/ f0 j% l. W  J( O0 X+ A: Y  cluster:1 P" ?& w. A' [8 z- B
    id:     8418d616-979b-46f9-ab95-b8fb20093d1b: w# g: |1 E2 i  S: [$ r$ l
    health: HEALTH_WARN
) A3 P* f7 F! C2 a" Q. b+ |            1 filesystem is degraded7 \0 s( b5 [+ F6 Y
            1 MDSs report oversized cache3 Z& h- A& G) _' D/ `( d
            1 MDSs report slow metadata IOs
5 j! I6 W8 \8 u9 e* o+------+--------+----------------------+----------+-------+-------+! `$ J; P% O- l* \7 X" v! }0 k/ L
| Rank | State  |         MDS          | Activity |  dns  |  inos |- z2 A* G3 r! R# Y; }0 ?6 |# f
+------+--------+----------------------+----------+-------+-------+
7 m% Z! F! p% \|  0   | rejoin |R03-MTEST-MN-001.xx.cn|          | 59.5M | 59.5M |1 u& J- C: O/ L2 [% T
+------+--------+----------------------+----------+-------+-------+
1 [" _1 s' T* o! H' Q8 w
+ W" }1 U4 a; V0 h9 x此时mds的内存消耗非常大5 L1 @9 o0 q0 e
: S8 o0 N4 I" H
    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND0 d8 }0 T4 K* A3 ]6 ]. w
150540 ceph      20   0  224.9g 223.5g  11704 S 100.0 89.0 196:15.69 ceph-mds
. @, w) h; Y! x- V3 ^% U( n. Q/ x# _& K2 x
使用命令ceph daemon run/ceph/ceph-mds.R03-MTEST-MN-001.xx.cn.asok flush journal4 ?$ w% p8 m2 b# I& \
后，降低了一些，但很快又上到了223G
! t3 p9 N5 u- ]6 B* V* F: u9 N! |& X1 h6 w( }9 r3 R( x
从结果上看，该版本的mds主要是没有解决内存的问题，没写多少文件，内存就直线飙升，而且居高不下，妄想重启mds，那就直接玩完
$ d: H" D! ^; z* O5 S& X: r. |1 g" `2 @7 j
这里直接给出13.2.10的建议：不行！事实上，14.2.x之前的版本都不建议使用cephfs上生产环境
) H6 k2 m( H% F% A) ^1 k  x; B; m; ]2 ~/ g( j
14版本的表现( f# w. B  ~$ R8 i
在这个版本的测试用，我加入了额外的data pool，并使用了多活mds，直接测试的小文件写入
; p" S2 G5 g, @: P0 l% A7 b
! b8 m* X4 o1 R" s[twj@R03-MTEST-MN-001.xx.cn test-cephfs]$ sudo ceph fs status
  ^9 `" ]  I# b$ Q; ?cephfs - 40 clients
: r# X. Q' x0 ^+ G. N======9 T$ h( g* _/ N( ~1 H: T+ b
+------+--------+------------------------+---------------+-------+-------+
  z8 j5 u9 J- V3 B: k1 x| Rank | State  |          MDS           |    Activity   |  dns  |  inos |
. r) ?# B4 x8 h" G, O& l$ C+------+--------+------------------------+---------------+-------+-------+
+ j" X7 p: }  B! }$ E|  0   | active | R03-MTEST-MN-003.xx.cn | Reqs: 10.3k/s |  391k |  391k |" z  Y4 d7 w2 a6 L) u" V! t) g1 H' n
|  1   | active | R03-MTEST-MN-002.xx.cn | Reqs: 10.5k/s |  385k |  385k |- \% `- G$ h- u8 p
+------+--------+------------------------+---------------+-------+-------+" K* c8 s' A' j6 y
+----------------------+----------+-------+-------+) Y( o) V4 ^) Z) e/ v" M, v
|         Pool         |   type   |  used | avail |5 W) T8 A8 b0 P3 \
+----------------------+----------+-------+-------+- J% w! ~. k( h
| cephfs.metadata.pool | metadata | 3378M |  797G |
0 `: S" x- v0 l+ U) e! q|  cephfs.data.pool1   |   data   | 6085G | 1234T |7 ~, c4 E5 c. h; `2 E# D/ \1 [7 s
|  cephfs.data.pool2   |   data   | 2257G | 1241T |; F2 h. ~3 l! E6 z
+----------------------+----------+-------+-------+4 t; e" w( ?  A# d9 D
+------------------------+
8 l8 m1 p# v  T6 u" _% G|      Standby MDS       |
  R6 C$ s: v2 A+------------------------+
/ O* X' S; B' ^0 t& `7 J% ]& l4 n| R03-MTEST-MN-001.xx.cn |8 P! j" i4 I. s
+------------------------+8 D& k, Q  R0 n7 ]8 U% D
MDS version: ceph version 14.2.20 (36274af6eb7f2a5055f2d53ad448f2694e9046a0) nautilus (stable)
  w; k: l1 t3 x+ n- ]4 N/ N( i( Y9 V+ B# }+ v8 V, K
其中每个data pool都创建了20个目录，并pin到不同的mds上，性能看还算均衡，连续快速写入，会有告警2 MDSs behind on trimming# h; ^( M; r6 N" \, w2 ~5 L+ U  W4 s
但没有什么影响，就没管
5 i* h9 B1 L/ b. B* P
& k& s8 u7 v3 h9 Z, v& f( l随着数据的大量写入，集群开始出现slow% Z. J0 A8 k+ a  ]9 S# b

/ p, K/ U$ V4 L' `% Q[twj@R03-MTEST-MN-001.xx.cn ~]$ sudo ceph df
" N$ L  @" z: S1 Z5 w! ?RAW STORAGE:$ W4 ?/ {$ ?+ F( G' i- R) {+ l
    CLASS     SIZE        AVAIL       USED        RAW USED     %RAW USED+ |2 O; M% |, e
    hdd       3.9 PiB     3.1 PiB     823 TiB      823 TiB         20.79
# x5 ^0 F( h# j8 J# u* j! l    ssd        16 TiB     3.0 TiB      13 TiB       13 TiB         80.727 g/ X2 k0 T! w. u
    TOTAL     3.9 PiB     3.1 PiB     835 TiB      836 TiB         21.03
( O+ I, ^% h" |! d- [' S# `6 x* c/ ]" P0 b& S0 }9 J3 q# G
POOLS:
0 E: x) v6 S$ M; b/ f/ F    POOL                     ID     PGS      twjD      OBJECTS     USED        %USED     MAX AVAIL
" b8 \, {, I' B1 [9 P* L2 v4 Q; d    cephfs.data.pool1         2     8192     275 TiB     217.81M     413 TiB     23.20       911 TiB/ v  ]5 p7 [# G# j
    cephfs.data.pool2         3     8192     244 TiB     102.44M     366 TiB     20.53       946 TiB
( X! k1 U* P% O) s    cephfs.metadata.pool      4      256     127 GiB     115.39k     191 GiB      7.74       760 GiB
& n) A# X( M7 ]) d: M* U" c, i    ; a" A- h+ f1 F- O( b
[twj@R03-MTEST-MN-001.xx.cn ~]$ sudo ceph health detail
4 Q2 [8 R) x- O' e/ B5 kHEALTH_WARN 1 MDSs report slow metadata IOs; 1 MDSs report slow requests
' H! \7 [" @% j; Y/ W1 _- ^MDS_SLOW_METADATA_IO 1 MDSs report slow metadata IOs3 m- b1 Z  |1 \( e% M) H. v3 i
    mds.R03-MTEST-MN-002.xx.cn(mds.1): 100+ slow metadata IOs are blocked > 30 secs, oldest blocked for 87 secs
/ P% u2 w; v4 W! d* i) dMDS_SLOW_REQUEST 1 MDSs report slow requests3 S1 w" A2 G5 M1 j1 n) l
    mds.R03-MTEST-MN-002.xx.cn(mds.1): 11 slow requests are blocked > 30 secs7 A  E) m8 ~$ c1 D
/ x" h# [7 C+ R( r7 ^. h- a& T
查看mds的op处理流程
, E$ i+ j8 t" {9 d
8 v5 s, J9 ?2 P: D* O- ][twj@R03-MTEST-MN-002.xx.cn ~]$ sudo ceph daemon mds.`hostname` dump_historic_ops_by_duration|grep duration! w( E( a7 S' c5 G" g
    "duration": 600,
6 D% f9 F. K& J! n- R            "duration": 427.63886984499999,: L) W% Z/ e' S6 M  d5 \
            "duration": 427.62001601499998,) t9 F' z& m7 O8 e* }$ z
            "duration": 409.772382456,
, r2 S: X* R$ P6 ]1 C9 p, I            "duration": 409.75990740399999,- F4 B" D0 g# S+ a
            "duration": 215.47288510800001,: N* c  i- o  _# x( `
            "duration": 214.47418489699999,
" c9 p; q. E2 s- x; X. t9 K) K: ^            "duration": 203.97045117499999,
7 T7 m8 w8 G% i0 j7 ?            "duration": 203.51505527899999,( ~4 Y/ r0 v' W' R) ~) ^
            .../ _) z1 A% U0 U- N: ]) l# R
1 ?/ [9 u1 n/ G$ u' \
时间都非常久，继续排查，发现大量的op都是卡在failed to rdlock, waiting
6 h3 Z  @$ A% l9 z' h& J0 v这个步骤，关于这种情况的调查和优化，还在努力。。。3 C! |$ B5 |2 B- H) j( w/ E) t

+ b5 C  X6 a. b& ?; v9 P看了一眼内存，没有明显的飙升. X( O  M" \9 ?5 a* B6 z

! g4 n1 @) Q' B6 d4 N$ j/ U9 X2 L5 |[twj@R03-MTEST-MN-003.xx.cn ~]$ top9 c$ A; p# O! f2 V8 m
top - 15:34:57 up 9 days,  4:36,  1 user,  load average: 0.95, 1.22, 1.28# D4 W7 [5 r/ s7 X% V5 W- r4 y
Tasks: 650 total,   1 running, 649 sleeping,   0 stopped,   0 zombie2 x, Y8 K# Q# l' H; p
%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
3 i6 @3 d) u. g0 t% a5 `KiB Mem : 26353089+total, 25013656+free, 11907872 used,  1486464 buff/cache
' ^: Z8 m/ E! O3 C0 KKiB Swap: 16777212 total, 16777212 free,        0 used. 24535932+avail Mem
  W6 O8 v8 x* V% E" \' K* o) {/ ]5 L% S* |  U. j1 h
    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
9 x0 K  H3 y( `: P- K  29657 ceph      20   0 7878864   2.5g  14288 S 100.7  1.0   4616:55 ceph-mds; Y% A2 p0 w! \# R

! ?8 M! Z2 C7 r  l4 J. g, p大量数据写入后，先测试一下mds的重启，直接reboot节点，观察集群的情况
- \/ q+ D+ G2 R4 [8 I% G  B. u; f% P4 L8 ]+ H! r0 X- \. I
[twj@R03-MTEST-MN-002.xx.cn ~]$ sudo ceph fs status
3 p/ o! J6 M6 C: q  W7 i% ecephfs - 40 clients
6 T1 t" B& Q. S$ e  d7 y======
4 f* U9 a- T! v/ @+------+--------+------------------------+---------------+-------+-------+0 V5 Q5 f0 F. K8 Y% x) w  y
| Rank | State  |          MDS           |    Activity   |  dns  |  inos |+ w4 i3 V. `% ]( W+ z- n, S, F
+------+--------+------------------------+---------------+-------+-------+
; C6 K  Z: B% q2 q|  0   | active | R03-MTEST-MN-001.xx.cn | Reqs:  869 s |  445k |  445k |
5 C2 Z) b" W# k' c4 y6 s|  1   | active | R03-MTEST-MN-002.xx.cn | Reqs:    0 s |  365k |  365k |0 x5 |# |  Q0 {8 s2 f8 {* [& j3 V
+------+--------+------------------------+---------------+-------+-------+
# v  l; B6 ~+ |+----------------------+----------+-------+-------+& ?5 K# m, ]( }9 g
|         Pool         |   type   |  used | avail |  }) P- s4 E; x
+----------------------+----------+-------+-------+( M. E: I/ K5 V
| cephfs.metadata.pool | metadata |  186G |  762G |3 `  H& x' E  n& {( D% ~
|  cephfs.data.pool1   |   data   |  412T |  910T |* @9 y( q" J0 Z% t6 M* D
|  cephfs.data.pool2   |   data   |  366T |  945T |
% Z+ o& g% \; m' b9 u5 {+----------------------+----------+-------+-------+. F- H" C; L& o& n
+------------------------+
. e1 d1 p$ _8 O* i|      Standby MDS       |. m/ m: g' g. D9 A
+------------------------+! b, I: y  ]0 K7 Y# R% G- ?
| R03-MTEST-MN-003.xx.cn |
- W* ~& T+ B' i6 q3 H$ x3 d, b+------------------------+8 r; q6 d4 K* _6 q. G1 |. `
MDS version: ceph version 14.2.20 (36274af6eb7f2a5055f2d53ad448f2694e9046a0) nautilus (stable)# Z1 v0 p3 a7 V$ X: G

- o; e  m9 s! N" _" t看是备是直接顶上了，mds重启后自动做备，业务侧暂时没有发现有问题，不过，发现写入的流量都打到了同一个mds，不知道是不是因为rank序号变化导致的
  U8 T; Y8 c3 A* @7 S( U% K' I$ O: |
测试发现，当单个目录对象数达到千万级时，cephfs的目录出现明显的卡顿，测试读，读取偶尔会有问题，流量不稳定，最大可到1GiB/s，最小只有几百M
% C  b) l; t* g! i1 d3 o4 i  i/ y9 B- D- C! X) l
  io:
) k+ w/ }* g6 G! A. N0 l9 L    client:   240 MiB/s rd, 559 KiB/s wr, 102 op/s rd, 0 op/s wr1 r$ G) _0 N3 M" y; H7 y% r& J
1 a+ v' H8 t1 M. Q' b7 V( J1 Q
结论  }( C0 i" Z" i" P8 I7 i5 [& s: {- e
cephfs 14.2.20测试结果来看，稳定性可靠性还是可以的，至少内存的问题看来是解决了，没有出现持续大量数据写入时产生的高内存占用问题，同时，重启其中一个rank，备用的mds会自动顶上，业务没有太大影响，而且，目录内的文件数量只要不是太大，小于百万级的话，性能也没有太大的问题，因此，14.2.20及后续版本的cephfs应该是可以上生产的了
! J2 g3 T, s* ]' @5 O5 B8 I+ _: y; d  L7 F
反观此前的版本，12、13都比较拉垮，mds不太靠谱，如果client有故障，读写卡住，mds分分钟给你瘫痪，极具危险性，还是不建议上，如果已经有在线的fs，还是强烈建议迁移到14.2.20+的版本, k0 B  ^8 n6 u2 n
% H/ K7 v8 |) v; J9 i0 `% y
下一步，将继续测试cephfs的其他异常情况和大规模数据写入后slow req的问题，并对代码逻辑方面进行一些分析，敬请期待^_^; L, C' i' k; A$ S( W- D5 F* Q* ?
( I0 R$ M" R% ?; p  c$ z
回复

举报

admin

1

主题

0

回帖

12

积分

管理员

积分
12
QQ
 楼主| 发表于 2023-2-3 21:14:28 | 显示全部楼层
一、pg相关#- [% Q% Y0 V6 d/ d7 N8 T: t
1、xx objects unfound#3 Q0 n% e3 H3 v
- 问题描述：#- `5 L( O) z7 L% L& I( t1 T0 k
dmesg查看磁盘发现读写异常，部分对象损坏（处于objects nofound状态），集群处于ERR状态- ]( b& ~% z. \, |- Q5 @% v
. G* }$ Z% ^* j- J
root@node1101:~# ceph health detail6 W0 r( U. E: }
HEALTH_ERR noscrub,nodeep-scrub flag(s) set; 13/409798 objects unfound(0.003%)；17 stuck requests are blocked > 4096 sec. Implicated osds 38
# ]7 }  D- l! u1 C" z. FOSDMAP_FLAGS noscrub,nodeep-scrub flag(s) set
; {% P( H: [) `5 b& bOBJECT_UNFOUND 13/409798 objects unfound (0.003%)+ S, G, o/ y1 C2 d
  pg 5.309 has 1 unfound objects  ]* C2 r3 K7 H  [  i$ C# A
  pg 5.2da has 1 unfound objects
9 O0 v" \. E. c0 T# ]* a+ R  pg 5.2c9 has 1 unfound objects1 m  M2 I8 a6 k& ?$ C5 a0 ]
  pg 5.1e2 has 1 unfound objects
7 ~0 x; L3 b# D# e0 N) u+ {  pg 5.6a has 1 unfound objects+ j( o7 L( K. I6 t
  pg 5.120 has 1 unfound objects
* Q" {1 A$ \& b: m" |6 S  pg 5.148 has 1 unfound objects6 a0 U" `) t& M1 G" ^
  pg 5.14b has 1 unfound objects
% [9 S! T$ [4 D; y/ C# f' e9 l0 C& F  pg 5.160 has 1 unfound objects
+ ^5 n" e$ Q* C  g6 Z  pg 5.35b has 1 unfound objects5 i% j1 G1 a5 O
  pg 5.39c has 1 unfound objects
  C! d* L7 u/ D  pg 5.3ad has 1 unfound objects
% Z* v# c  p) @0 x; _% }REQUEST_STUCK 17 stuck requests are blocked > 4096 sec. Implicated osds 38
$ c. ^7 s# j( C9 M+ B' V* a  17 ops are blocked > 67108.9 sec
! i# I2 J8 R/ h# L  osd.38 has stuck requests > 67108.9 sec
% v( s; u8 M% O9 ^4 J$ Z- 处理措施：#
* L5 x) G0 U9 a$ n) \. R& ]将unfound pg强制删除，参考命令：ceph pg {pgid} mark_unfound_lost delete
; J/ n1 I/ j/ H: ]# m; p! [注：如需批量删除unfound pg，则参考命令如下
! m- O3 ]8 W# h8 a: p% n- n. l: o# r$ A  u/ b
for i in `ceph health detail | grep pg | awk '{print $2}'`;do ceph pg $i mark_unfound_lost delete;done
+ o% }/ G; f& ]$ E/ D& n3 P2、Reduced data availability: xx pgs inactive#
) i0 N7 c5 n! {. j& L+ B8 [- 问题描述：#5 S" r5 k3 R7 U) V1 @7 `
磁盘出现读写异常，osd无法启动，强制替换故障盘为新盘加入到集群，出现pgs inactive（unkown）
; n( V* A; D! `- K
' y* _7 L) V% [$ E6 e" w. w3 _root@node1106:~# ceph -s
" u  R8 R) j- N+ ]  cluster:! o6 |& h! o8 w
    id:     7f1aa879-afbb-4b19-9bc3-8f55c8ecbbb43 K( S1 m  O) v
    health: HEALTH_WARN! o3 o2 O. c2 G
            4 clients failing to respond to capability release1 B" b1 ]- V0 [& `9 \: H
            3 MDSs report slow metadata IOs
$ w, A, J3 m# ~( c6 n. G            1 MDSs report slow requests5 H* J% m; K5 G2 Q9 v$ V" a
            3 MDSs behind on trimming
: c/ a" i1 L  {2 W" e            noscrub,nodeep-scrub flag(s) set5 ^; ~( e5 w; d/ Q
            Reduced data availability: 25 pgs inactive
# a: W# A& @3 ~. a2 _            6187 slow requests are blocked > 32 sec. Implicated osds 41
$ h% c2 X5 |+ s+ O/ u# S; `) U( E' E, P/ j, y8 A: }

/ G4 B) O8 @9 l, A  services:" F5 w1 c3 Q" H
    mon: 3 daemons, quorum node1101,node1102,node1103& ]4 {5 s) v! N0 d1 i3 B  ?
    mgr: node1103(active), standbys: node1102, node1101
2 m/ J: r% |. i- l3 E    mds: ceph-3/3/3 up  {0=node1103=up:active,1=node1102=up:active,2=node1104=up:active}, 2 up:standby7 ^' Q6 b3 J' K7 z
    osd: 48 osds: 48 up, 48 in
: x/ D- D+ r/ }* M5 M         flags noscrub,nodeep-scrub7 i$ X. i0 f) e7 `: a- P) S

: _3 C6 x, T0 |1 z, a  }  k$ S$ F) a0 {1 v2 r
  data:
) ~8 v& C7 |# H9 L3 i8 b" x    pools:   6 pools, 2888 pgs
4 j( f2 k3 |% d. u- d    objects: 474.95k objects, 94.5GiB6 |) z$ {7 o: y, L% m4 t  \# R  q
    usage:   267GiB used, 202TiB / 202TiB avail! y; G; V  x; J0 L, p  J- c! ^
    pgs:     0.866% pgs unknown
! z( v( ]" w# w/ d' I. K             2863 active+clean
; g8 r! z+ y$ w9 k             25   unknown
  H7 `; o5 P$ J6 C& A
- M; z7 z. U: V6 v: E
3 M, X# K# i6 R# ]$ hroot@node1101:~# ceph pg dump_stuck inactive
6 b+ F% l( V. N# ~( u( N# }ok! i0 a7 \- T7 C* r
PG_STAT STATE   UP UP_PRIMARY ACTING ACTING_PRIMARY
8 h" x+ c6 G- x4 [3 m: K& s; X) a1.166   unknown []         -1     []             -1
/ |, e3 e7 F  n( R  w' Z1.163   unknown []         -1     []             -1 2 r6 v& u. e: r# A
1.26f   unknown []         -1     []             -1 * K- V0 e) a# W6 h) z) E
1.228   unknown []         -1     []             -1 + w7 V' j* P% u+ ?2 x& j
1.213   unknown []         -1     []             -1
5 t% d0 s, p/ R% n# }  O1.12f   unknown []         -1     []             -1
" z6 U5 ^& A4 v1.276   unknown []         -1     []             -1
$ @; s0 L- I6 x( s. \1.264   unknown []         -1     []             -1
! O. J; ~- f, \, e5 e% M& y5 ]1.32a   unknown []         -1     []             -1
0 S$ ?1 s5 q" X1.151   unknown []         -1     []             -1
" j* ~+ t& F6 W3 ?+ O9 ~6 f9 C1.20d   unknown []         -1     []             -1 9 ~, H! {7 `8 t) ]# n4 O1 @
1.298   unknown []         -1     []             -1
- G! S0 Z9 M$ J: U" x3 U4 D1.306   unknown []         -1     []             -1 ) R# v$ x2 s/ v) Q
1.2f7   unknown []         -1     []             -1
; V# D; y6 Z/ w/ s3 t1.2c8   unknown []         -1     []             -1 6 y- V2 ?) q: @. ~
1.223   unknown []         -1     []             -1 2 [; ?, L' E2 Q- C# c* t: B
1.204   unknown []         -1     []             -1 . a8 H7 X& I6 j0 _1 `' k4 [# r
1.374   unknown []         -1     []             -1
- x" s0 l7 O5 x6 q1 Y1.b5    unknown []         -1     []             -1 / |- F& F: |: O. H4 S4 b
1.b6    unknown []         -1     []             -1
2 Y1 Q! O% b/ O* \6 D1.2b    unknown []         -1     []             -1
: T5 `. f' ]3 X1.9f    unknown []         -1     []             -1 9 G% L6 [+ {1 U
1.2ac   unknown []         -1     []             -1 4 m: {2 @" m$ `) y8 q$ ~
1.78    unknown []         -1     []             -1
7 d! f5 m  I2 l+ }5 [0 |1.1c3   unknown []         -1     []             -1
$ M( K2 t2 b, y9 L1.1a    unknown []         -1     []             -1
3 E# @, L" t, }8 m+ q. M' `: T1.d9    unknown []         -1     []             -1   h0 U3 `( O% Z7 K
- 处理措施：#5 Z* Z: `* B) a! L0 M) Y) }; ~
强制创建unkown pg，参考命令：ceph osd force-create-pg {pgid}
. u) F' l( v  T' b( I注：如需批量创建unkown pg，则参考命令如下：
- i: I( f. [# [# D( Y. H) l+ G: [/ V! q
for i in `ceph pg dump_stuck inactive | awk '{if (NR>2){print $1}}'`;do ceph osd force-create-pg $i;done* V0 T) i7 o7 E7 B
二、OSD相关#
$ B9 w4 E) u: Z6 Z* R1、osd端口与其他服务固定绑定端口冲突#' V# ^0 n! `( f6 N& R
- 问题描述：#7 v: J9 T& P; t* y9 u% X
osd先行启动，占用其他服务固定绑定端口，导致其他服务绑定端口失败，无法启动( U; b1 n1 u" r3 n& w4 O* j$ G

; P6 ~0 A) o7 T2 n. z+ U- 处理措施：#8 \: n4 R! h7 l1 G2 A9 c. a4 b
考虑到其他服务涉及组件太多，担心修改不完全导致其他问题发生，尝试修改osd启动端口范围为其他服务之外7 `$ w& m& w( X: N# r
' _4 I7 n  `2 H- L$ U
修改osd作为服务端的启动端口范围0 Y( `) @* }; y5 G0 h$ J
ceph可通过ms_bind_port_min和ms_bind_port_max参数限制osd和mds守护进程使用端口范围，默认范围为6800：73000 G% n) `6 o# x8 L: A- c1 b. B+ w) r. H
设置端口使用范围为9600:10000，追加参数设置至/etc/ceph/ceph.conf文件中[global]字段内7 E1 w9 r% V; h; G$ H
[root@node111 ~]# cat /etc/ceph/ceph.conf | grep ms_bind_port
! P' V* D# \& F- Gms_bind_port_min = 9600
- Z: C  b4 }9 N6 D  d" M& o' Xms_bind_port_max = 10000! m1 A- R& w% b5 @2 L% A
[root@node111 ~]#
! n) \% h9 R5 L5 V3 y7 A[root@node111 ~]# ceph --show-config | grep ms_bind_port
& a- U, P0 d  l0 wms_bind_port_max = 100008 \6 ?9 L/ Y& M
ms_bind_port_min = 9600
9 u+ ~& H6 [# y' r' q2 v修改osd作为客户端的启动端口范围1 y; x- Q6 @7 o( o, T: y9 K9 P0 y+ N
osd作为客户端的启动端口为随机分配的，可通过内核去限制随机端口分配范围
% C6 A) Z  t! B! J/ i默认端口范围为1024：65000，修改端口范围为7500：65000
" i, C: B% B3 k& O$ _7 `3 q4 P--默认端口范围为1024：65000
  U9 D# b- r  ][root@node111 ~]# cat /proc/sys/net/ipv4/ip_local_port_range 7 G" s, J0 ~5 d/ w
1024    65000
4 t; Y' A! U' W7 ~--修改范围为7500：65000; ?- ]* J; b! e; u7 @) ~7 Y+ G
[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
8 Y# e8 }7 r$ e# i8 @; l/ Q  [4 C[root@node111 ~]# sysctl -p% q5 n2 m! X* t$ ]
2、磁盘热插拔，osd无法上线#
$ U/ c: ~$ }/ n- 问题描述：#
6 H% U% n3 h- R3 C, c- N( ^使用bluestore部署ceph集群，对osd所在磁盘进行热插拔操作，当重新插回之后，osd对应lvm不能自动恢复，导致osd无法上线成功
% l' D% l  y6 y' X' ~' T+ C, V, p* y- N& k* d( [
) r0 h- h  x! N7 H: `, N7 L
9 G( b$ C! X6 O. M  ]
- 处理措施：#
0 v$ m* b6 }1 w查找故障osd对应uuid：- Y3 G5 O6 z& e
ceph osd dump | grep {osd-id} | awk '{print $NF}'# i5 O1 r+ {& c# G5 M/ f; l: v" d
参考示例：查找osd.0对应uuid
0 f( h6 Q( }2 L& S& {, ], a[root@node127 ~]# ceph osd dump | grep osd.0 | awk '{print $NF}'
3 V, ]6 w0 G* {- N57377809-fba4-4389-8703-f9603f16e60d# }' x2 a8 N! u- Y! F# o+ T
查找故障osd对应lvm路径：
+ l& e( ~: X2 o2 jls /dev/mapper/ | grep `ceph osd dump | grep {osd-id} | awk '{print $NF}' | sed 's/-/--/g'`
! x) F, `7 [0 S7 _3 b# m' T4 P参考示例：通过uuid查找对应lvm路径. H. e9 @  C  x4 _
注：由于lvm路径对uuid做了处理，需要sed 's/-/--/g'`将-替换为--
% T+ `& d: ~) L. G5 m! a7 c[root@node127 ~]# ls /dev/mapper/ | grep `ceph osd dump | grep osd.0 | awk '{print $NF}' | sed 's/-/--/g'`# \5 b+ U- ^/ H) I% z' c, I
ceph--3182c42e--f8d8--4c13--ad92--987463d626c8-osd--block--57377809--fba4--4389--8703--f9603f16e60d+ M/ E; @# K' m6 m
删除故障osd对应lvm路径
  l, [4 c3 x0 j3 h( Gdmsetup remove /dev/mapper/{lvm-path}4 d* Q; I& L! P- S! t
参考示例：删除故障osd对应lvm路径
1 `) F5 P8 v* M# b( H- z7 e[root@node127 ~]# dmsetup remove /dev/mapper/ceph--3182c42e--f8d8--4c13--ad92--987463d626c8-osd--block--57377809--fba4--4389--8703--f9603f16e60d ( D! v3 t4 N% V5 `( |1 V
重新激活所有lvm卷组
; P9 N2 I* ~9 j( h9 e注：此时可以查看到对应故障osd的lvm信息+ y! ^% f9 d" q2 x+ Z* `
vgchange -ay5 k/ o& r% ?9 c3 C/ g
重新启动osd使得osd上线
5 e% A, r6 m4 jsystemctl start ceph-volume@lvm-{osd-id}-{osd-uuid}
0 m9 A1 A& f% k* a三、集群相关#
/ [( A) B4 a  z- f% C1、clock skew detected on mon.node2#
& o0 ?. ?4 L+ D" f! t0 `+ |( R- 问题描述：#
. e5 i% S; R2 ^$ H5 s' t: G% e集群mon节点时间偏差过大，出现clock skew detected on mon.node2 告警信息/ U2 P2 ]4 u& g8 t2 [
( J4 \. A0 m2 I9 T
- 处理措施：#
/ T4 y, I# y" @8 G) K1、检查集群mon节点时间偏差，使用chronyd时间进行集群时间同步
4 S+ E. L$ W: _" B2、调大集群参数阈值，调整mon_clock_drift_allowed 参数值为2，调整mon_clock_drift_warn_backoff 参数值为30
- G: r. h# ^* V& x% u, t# ]: D% M" a+ r, m( Q+ _, F7 C
sed -i "2 amon_clock_drift_allowed = 2" /etc/ceph/ceph.conf
1 v9 g4 f# G4 o8 L# Wsed -i "3 amon_clock_drift_warn_backoff = 30" /etc/ceph/ceph.conf
0 F% o: j6 \- Kceph tell mon.* injectargs '--mon_clock_drift_allowed 2'6 |" @7 U4 T7 T1 z5 m: l3 l
ceph tell mon.* injectargs '--mon_clock_drift_warn_backoff 30'
  v0 D" X6 z* B5 t) V5 t7 t! E注：相关参数说明如下：6 @& k$ r2 E; \6 Q
  T, \, V7 c1 h. E5 s$ M) ]  Y
[root@node147 ~]# ceph --show-config | grep mon_clock_drift
( b4 V& X! E: p6 ]1 w8 y# ~2 H6 Zmon_clock_drift_allowed = 0.0500008 H9 z7 K" c) n9 r
--当mon节点之间时间偏移超过0.05秒，则不正常( g! y9 ?; Q; @9 [9 E  s" c
mon_clock_drift_warn_backoff = 5.000000
' }% l' Y; r7 y7 m--当出现5次偏移，则上报告警
回复

举报

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

本版积分规则

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

GMT+8, 2026-6-12 00:06 , Processed in 0.022654 second(s), 23 queries .

Powered by Discuz! X5.0

© 2001-2026 Discuz! Team.

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