Ceph节点故障触发重平衡,导致IO堆积,大量SLOW OPS卡死OSD,引起虚拟机无法写入

Ceph节点故障触发重平衡,导致IO堆积,大量SLOW OPS卡死OSD,引起虚拟机无法写入

Deng YongJie's blog 1,518 2024-06-16

Ceph节点故障触发重平衡,导致IO堆积,大量SLOW OPS卡死OSD,引起虚拟机无法写入解决方法

由于1台节点主板电压不稳,突然暴毙。大概有40T数据,此节点宕机后,触发Ceph的重平衡机制,此时磁盘占用大量IO,然后影响到虚拟机的读写性能和可用性,最后导致Ceph堆积了大量IO在排队处理,造成虚拟机可能出现这些情况:IO路径闪断、操作系统瞬间无法写入、无法开机、IO资源争抢。

主要原因是:

  1. crushmap规则里面的故障域没有改成host,导致3副本都在同一台节点
  2. 故障节点硬盘可以不用格式化,禁止集群重平衡,重新把故障节点加入集群尝试激活旧的硬盘
  3. 把故障节点的硬盘格式化了,重新加入集群,导致丢失部分PG,而集群认为PG的ID是存在的,实际上,这些数据块并不在磁盘了,所以一直堆积着

首先查看IO是否被阻塞,如果被阻塞了,证明前面有任务IO在排队,导致后面的也无法写入,没有流量进来。下图就是IO被堆积阻塞了,由于把旧的盘格式化,节点还是旧的系统,重新加入集群,主机名和IP都是一样的,导致去操作部分PG时,实际上数据块没有在磁盘了,一直hang住,堆积阻塞着,后面的任务IO无法处理。Ceph是处理完第一个IO完整的请求之后,才会处理第二个的

image-20230809215053598

image-20230809215431808

image-20230809215256344

告警里面一堆的slow ops,就是那些空的数据块在卡着

PG_AVAILABILITY: Reduced data availability: 29 pgs

查看mon日志、mds日志、osd日志
tail -f -n 200 /var/log/ceph/

首先查看告警上面的PG是否存在,如果不存在了,那只能重建PG
ceph pg 6.14 query
Error ENOENT: i don't have pgid 6.14

不存在这个PG了,只能重建,否则会一直卡着这些IO
逐个PG都要重建
ceph osd force-create-pg 19.15a  --yes-i-really-mean-it

上面重建完PG之后,如果还有部分OSD处于slow ops,需要手动重启这几个OSD

image-20230809215605314

先看日志有没有slow ops的提示,然后逐个OSD重启
tail -f -n 200 /var/log/ceph/ceph-osd.50.log
systemctl restart ceph-osd@50


然后集群就能恢复正常读写,处理IO了。但是还会出现unknown的PG,只能修复,修复不了只能回滚或删掉

image-20230809215824264

先看下unknown的pg是否实际存在?如果还有1个osd存在该pg副本的,则尝试修复,修复PG的在下面PG数据损坏有流程,比较麻烦。修复不了只能删掉

image-20230809215934242

删除unknown的pg的命令
ceph pg 27.13 mark_unfound_lost delete 

get_health_metrics reporting 3 slow ops的解决办法!

查看集群状态发现慢请求的osd告警:

OSD_SLOW_PING_TIME_BACK: Slow OSD heartbeats on back (longest 3160.225ms) OSD_SLOW_PING_TIME_FRONT: Slow OSD heartbeats on front (longest 3011.094ms)

SLOW_OPS: 4 slow ops, oldest one blocked for 970 sec, osd.11 has slow ops

osd日志发现:

osd.11 31902 get_health_metrics reporting 4 slow ops, oldest is osd_op(client.145746656.0:142372 17.ee 17:77588fb0:::rbd_data.3c1db779e4202a.0000000000000105:6 [sparse-read 0~1048576] snapc 0=[] ondisk+read+known_if_redirected e31902) log_channel(cluster) log [WRN] : 4 slow requests (by type [ ‘reached pg’ : 1 ‘delayed’ : 3 ] most affected pool [ ‘hz-c1-basic-wrk-pve-cache’ : 4 ])

相关慢ops的案例:

https://forum.proxmox.com/threads/ceph-sudden-slow-ops-freezes-and-slow-downs.111144/

https://github.com/canonical/hotsos/issues/302

https://github.com/canonical/hotsos/pull/313/commits/f4f7c7d191f887f06af92f31bd1116320478f94f

image-20231012095523902

image-20231012095535429

问题原因:因为osd是机械硬盘,导致nvme缓存层的大量IO卡住,卡住原因是由于nvme缓存盘线程较多,直接把整个节点的内存吃完,导致触发内核OOM。多个子操作执行速度慢,又导致IO等待时间增加,最后op_commit将操作结果写入osd机械硬盘存储,机械盘延迟较高,所以客户端新进去的流量,又触发NVME类型的osd缓存盘请求阻塞限流,引发多个osd震荡,最终节点CPU、内存突增OOM,以此恶性循环。

还有osd有逻辑坏道也会导致slow ops,延迟会非常高,虽然说不会有致命威胁,但会严重拉低性能。以下是逻辑坏道的警告信息:

[WRN] OSD_TOO_MANY_REPAIRS: Too many repaired reads on 1 OSDs** osd.32 had 13 reads repaired**

下图是op的全流程和时间:

通常整个流程是0.05秒,即是50毫秒以内才算正常。这里用了4秒多,有些甚至70秒,延迟非常严重

#查看op的完整流程
ceph daemon osd.11 dump_historic_ops_by_duration

#过滤一下时间
ceph daemon osd.11 dump_historic_ops_by_duration|grep duration

#查看osd的日志,找一下pg的号数对应的osd
ceph pg 6.e1 query|grep primary

#查看osd对应的磁盘io
iostat -xm 1

image-20231012150725735

image-20231012151003152

image-20231012151010719

image-20231012151019168

官方新版弃用了缓存层,不稳定有缺陷:

https://ceph.com/en/news/blog/2023/v18-2-0-reef-released/

https://github.com/feryw/linux-4.14.y/commit/3f376cc03766f2c1f98f63066700e7d1a3d94f0d

image-20231012182617557

image-20231012182623542

image-20231012182938818

解决办法:

#把ping_time调整3000ms或5000ms
ceph tell osd.* injectargs '--mon_warn_on_slow_ping_time 3000'

#升级物理服务器内存256G

#调整osd的system参数
OOMScoreAdjust=-1000
Restart=always

systemctl daemon-reload

#上面的步骤实在不行,如果还是暴增内存。那么只能把缓存层给刷盘,删除了
ceph osd tier cache-mode hz-c1-basic-wrk-pve-cache readproxy --yes-i-really-mean-it

rados -p hz-c1-basic-wrk-pve-cache cache-flush-evict-ail
#删除 overlay,这样客户端不会再访问缓存层
ceph osd tier remove-overlay hz-c1-basic-wrk-pve

#最后删除 缓存池
ceph osd tier remove hz-c1-basic-wrk-pve hz-c1-basic-wrk-pve-cache