文章目录
参考文章
1、别人也遇到过相同的问题（snaptrim 操作非常慢，阻塞客户端 I/O）
https://www.spinics.net/lists/ceph-users/msg75643.html
2、snaptrim中的qos
https://lovethegirl.github.io/2020/02/16/snaptrim_qos/
3、红帽ceph官方osd介绍文章
https://people.redhat.com/bhubbard/nature/default/rados/configuration/osd-config-ref/用户ceph场景
6台HDD存储节点|每台12块盘：以crush 中 osd class type 为 hdd 创建名为 volume-hdd，故障域是 host 级别
6台SSD存储节点|每台12块盘：以crush 中 osd class type 为 ssd 创建名为 volume-ssd，故障域是 host 级别
4台SAS存储节点|每台 6块盘：以crush 中 osd class type 为 sas 创建名为 vol-sas，故障域是 host 级别故障现象
现象一、sas存储节点，存储网卡流量图呈现周期性突降（且伴随存储节点CPU负载增加）
注意：我们观察到 仅仅是sas存储节点流量有周期性突降；其他类型的存储节点，流量正常，CPU负载也没有明显变化。
现象二、sas存储节点中osd日志，在流量突降期间，有pg slow日志，
（最初以为是某个osd有该日志，后面检查发现几乎所有sas存储节点osd均有间歇性pg slow日志）
root@lasas001:~# grep slow /var/log/ceph/ceph-osd.136.log | grep WRN
2023-12-06T20:16:02.377-0800 7f3c88c15700 0 log_channel(cluster) log [WRN] : 9 slow requests (by type [ 'delayed' : 9 ] most affected pool [ 'vol-sas' : 9 ])
2023-12-06T20:16:03.361-0800 7f3c88c15700 0 log_channel(cluster) log [WRN] : 2 slow requests (by type [ 'delayed' : 2 ] most affected pool [ 'vol-sas' : 2 ])
2023-12-06T20:16:04.397-0800 7f3c88c15700 0 log_channel(cluster) log [WRN] : 9 slow requests (by type [ 'delayed' : 9 ] most affected pool [ 'vol-sas' : 9 ])
2023-12-06T20:16:05.393-0800 7f3c88c15700 0 log_channel(cluster) log [WRN] : 7 slow requests (by type [ 'delayed' : 7 ] most affected pool [ 'vol-sas' : 7 ])
2023-12-06T20:16:06.373-0800 7f3c88c15700 0 log_channel(cluster) log [WRN] : 1 slow requests (by type [ 'delayed' : 1 ] most affected pool [ 'vol-sas' : 1 ])
2023-12-06T20:16:07.413-0800 7f3c88c15700 0 log_channel(cluster) log [WRN] : 4 slow requests (by type [ 'delayed' : 4 ] most affected pool [ 'vol-sas' : 4 ])
2023-12-06T20:16:08.369-0800 7f3c88c15700 0 log_channel(cluster) log [WRN] : 1 slow requests (by type [ 'delayed' : 1 ] most affected pool [ 'vol-sas' : 1 ])
2023-12-06T20:16:09.333-0800 7f3c88c15700 0 log_channel(cluster) log [WRN] : 18 slow requests (by type [ 'delayed' : 17 'waiting for sub ops' : 1 ] most affected pool [ 'vol-sas' : 18 ])
2023-12-06T20:16:10.321-0800 7f3c88c15700 0 log_channel(cluster) log [WRN] : 1 slow requests (by type [ 'delayed' : 1 ] most affected pool [ 'vol-sas' : 1 ])
2023-12-06T20:16:11.361-0800 7f3c88c15700 0 log_channel(cluster) log [WRN] : 5 slow requests (by type [ 'delayed' : 5 ] most affected pool [ 'vol-sas' : 5 ])
2023-12-06T20:16:12.365-0800 7f3c88c15700 0 log_channel(cluster) log [WRN] : 15 slow requests (by type [ 'delayed' : 14 'waiting for sub ops' : 1 ] most affected pool [ 'vol-sas' : 15 ])
2023-12-06T20:16:13.317-0800 7f3c88c15700 0 log_channel(cluster) log [WRN] : 2 slow requests (by type [ 'delayed' : 1 'waiting for sub ops' : 1 ] most affected pool [ 'vol-sas' : 2 ])
2023-12-06T20:16:14.317-0800 7f3c88c15700 0 log_channel(cluster) log [WRN] : 11 slow requests (by type [ 'delayed' : 10 'waiting for sub ops' : 1 ] most affected pool [ 'vol-sas' : 11 ])
2023-12-06T20:16:15.289-0800 7f3c88c15700 0 log_channel(cluster) log [WRN] : 5 slow requests (by type [ 'delayed' : 4 'waiting for sub ops' : 1 ] most affected pool [ 'vol-sas' : 5 ])
2023-12-06T20:16:16.281-0800 7f3c88c15700 0 log_channel(cluster) log [WRN] : 8 slow requests (by type [ 'delayed' : 7 'waiting for sub ops' : 1 ] most affected pool [ 'vol-sas' : 8 ])
2023-12-06T20:16:17.273-0800 7f3c88c15700 0 log_channel(cluster) log [WRN] : 1 slow requests (by type [ 'waiting for sub ops' : 1 ] most affected pool [ 'vol-sas' : 1 ])
2023-12-06T20:18:24.127-0800 7f3c88c15700 0 log_channel(cluster) log [WRN] : 2 slow requests (by type [ 'delayed' : 1 'waiting for sub ops' : 1 ] most affected pool [ 'vol-sas' : 2 ])第一步：故障分析
1、因为该流量图断层，呈现明显的周期性，（所以我怀疑，这跟业务强相关，必然受业务影响）
出现的时间点：0、6、12、18点
出现持续时长：大约50分钟（某个时间点的 10分 ~ 下个整点）
出现固定次数：四次
2、因为用户sas pool 是rbd类型的池，跑的是虚拟机磁盘，所以我们在下一个周期来临之前，使用 rbd perf image iotop vol-sas 命令查看有无异常。
第二步：故障分析
1、我们根据上图出现的虚拟机磁盘，在云系统上查询后得知。这两个虚拟机，分别设置了6小时的定时快照任务，且快照最大保存3份。（超过3份后会删除最老的快照）
2、我们发现这个两个虚拟机都属于同一个用户，再根据该用户进行查看，发现其名下 有 6台虚拟机，数据盘 都是2T的，且都设置了相同间隔时间的 定时快照任务。
kvm35784 40G+2T
kvm35002 40G+2T
kvm33332 40G+2T
kvm34262 40G+2T
kvm36627 40G+2T
kvm33550 40G+2T
3、根据已有知识，ceph在对image 进行快照拍摄时，不会有特别大的性能占用。且拍摄快照的时间 很短，不符合存储流量突降 持续 50分钟 的特征第三步：故障分析
1、在存储流量突降的时间范围内，查看 ceph 集群信息，发现有大量的pg 处于 snaptrim 和 snaptrim_wait状态 （发现当前共有 48+976=1024个 pg 处于snaptrim 、snaptrim_wait 状态）
root@lasas002:~# ceph -s
......
data:
pools: 4 pools, 7169 pgs
objects: 30.22M objects, 112 TiB
usage: 369 TiB used, 685 TiB / 1.0 PiB avail
pgs: 6137 active+clean
976 active+clean+snaptrim_wait # 注意这里，说明当前有976个pg正等待snaptrim
48 active+clean+snaptrim # 注意这里，说明当前有48个pg处于snaptrim
7 active+clean+scrubbing+deep+repair
1 active+clean+scrubbing+deep
io:
client: 606 MiB/s rd, 148 MiB/s wr, 13.30k op/s rd, 4.32k op/s wr
2、查询相关文档，pg处于这两个状态表示如下意思
snaptrim： # 删除快照后的快照回收操作；（注意：删除快照后，ceph还要进行快照回收，释放出多余的空间）
snaptrim-wait： # 由于每个osd并发的限制，已经有pg在做删除快照，那么其他的pg必须等待；
3、细心比对发现，48 + 976 正好等于 当前sas pool的pg数量 ，即 1024，且该sas pool 是由 4个 6盘位节点组成的。
也就是说共有 24个sas 类型的 osd，每个osd同时有两个pg 在进行snaptrim，这就导致了 osd出现slow ，阻塞了sas pool的写入读出IO
root@lasas002:~# ceph df
--- RAW STORAGE ---
CLASS SIZE AVAIL USED RAW USED %RAW USED
sas 168 TiB 106 TiB 62 TiB 62 TiB 37.00
......
TOTAL 1.0 PiB 686 TiB 368 TiB 368 TiB 34.90
--- POOLS ---
POOL ID PGS STORED OBJECTS USED %USED MAX AVAIL
vol-sas 6 1024 21 TiB 5.61M 62 TiB 41.22 29 TiB
......
4、查看当前osd关于snaptrim的相关配置
root@lasas001:~# ceph daemon osd.136 config show | grep snap_trim
"mon_osd_snap_trim_queue_warn_on": "32768",
"osd_pg_max_concurrent_snap_trims": "2", # 表示每个osd最大允许2个pg同时进行snaptrim
"osd_snap_trim_cost": "1048576", # 表示快照回收成本，该值默认是1M
"osd_snap_trim_priority": "5", # 表示快照回收snaptrim 队列优先级，类型是整数，范围是 1~63，数值越大越优先
"osd_snap_trim_sleep": "0.000000", # 表示osd执行两次snaptrim的间隔休眠时间，单位是秒，用来减轻负载。
"osd_snap_trim_sleep_hdd": "5.000000",
"osd_snap_trim_sleep_hybrid": "2.000000",
"osd_snap_trim_sleep_ssd": "0.000000",调优测试
A、调优思路：
1、减小每个osd同时允许最大多少个pg执行snaptrim，默认最大允许2个改为1个（即osd_pg_max_concurrent_snap_trims = 1）
2、降低 snaptrim 队列优先级，由原来的5 改成3。
3、增加 osd 执行 snaptrim 的sleep 时间，由原来的0 改成2。
B、调整方法一：修改ceph.conf配置文件中，[osd]板块内容，重启对应的osd
# 注意 B与C方法 都只适用于 ceph 15 和 ceph 16版本，对于ceph 17版本是不生效的
[osd]
osd_pg_max_concurrent_snap_trims = 1
osd_snap_trim_priority = 3
osd_snap_trim_sleep = 2.0
osd_snap_trim_sleep_hdd = 5.0
osd_snap_trim_sleep_hybrid = 2.0
osd_snap_trim_sleep_ssd = 0.0
C、调整方法二：直接用tell的方式，不用重启osd，直接生效
ceph tell osd.136 injectargs '--osd_pg_max_concurrent_snap_trims 1'
ceph tell osd.136 injectargs '--osd_snap_trim_priority 3'
ceph tell osd.136 injectargs '--osd_snap_trim_sleep 2'
D、第一步：单独仅调整 osd_pg_max_concurrent_snap_trims 为 1，实测没有效果，如下是下一个周期来临时查看到的数据，任然有48个pg 同时 snaptrim，流量图没有明显变化（据说要和另外的参数搭配使用）
root@lasas001:~# ceph daemon osd.136 config show | grep snap_trim
"mon_osd_snap_trim_queue_warn_on": "32768",
"osd_pg_max_concurrent_snap_trims": "1",
root@lasas002:~# ceph -s
......
data:
pools: 4 pools, 7169 pgs
objects: 30.22M objects, 112 TiB
usage: 369 TiB used, 685 TiB / 1.0 PiB avail
pgs: 6137 active+clean
976 active+clean+snaptrim_wait # 注意这里，说明当前有976个pg正等待snaptrim
48 active+clean+snaptrim # 注意这里，说明当前有48个pg处于snaptrim
7 active+clean+scrubbing+deep+repair
1 active+clean+scrubbing+deep
io:
client: 816 MiB/s rd, 248 MiB/s wr, 15.30k op/s rd, 5.32k op/s wr
E、第二步：在第一步的基础上，降低优先级，增加sleep时间
root@lasas001:~# ceph daemon osd.136 config show | grep snap_trim
"mon_osd_snap_trim_queue_warn_on": "32768",
"osd_pg_max_concurrent_snap_trims": "1", # 改动第一处
"osd_snap_trim_cost": "1048576",
"osd_snap_trim_priority": "3", # 改动第二处
"osd_snap_trim_sleep": "2.000000", # 改动第三次
"osd_snap_trim_sleep_hdd": "5.000000",
"osd_snap_trim_sleep_hybrid": "2.000000",
"osd_snap_trim_sleep_ssd": "0.000000",经E步骤调整后，集群存储流量不再有明显的长周期突降(因为延迟了pg的snaptrim时间周期)
附、ceph 集群设置 nosnaptrim 和 取消 nosnaptrim的相关知识
1、如果执行 ceph osd set nosnaptrim 命令会禁用 OSD 上的快照回收操作，这意味着删除旧的快照时，相关的空间回收操作将被禁用。
2、如果你随后执行 ceph osd unset nosnaptrim 命令来取消 nosnaptrim 属性，Ceph 将恢复对快照回收的正常操作。
3、在执行 ceph osd set nosnaptrim后，如果你在删除旧快照之前执行 ceph osd unset nosnaptrim，
快照回收操作将重新启用，旧的快照数据将被清理，释放存储空间。
4、在执行 ceph osd set nosnaptrim后，如果你在删除旧快照之后执行 ceph osd unset nosnaptrim，
快照回收操作将重新启用，但已经删除的旧快照数据将无法回收。这可能导致存储空间不再被释放，而是保留在系统中。
在后一种情况下，系统的存储空间可能会受到影响，因为已删除的快照数据将无法通过正常的快照回收过程来清理。
如果需要释放存储空间，你可能需要考虑其他手段，如手动清理不再需要的数据。声明：本文为原创，作者为 辣条①号，转载时请保留本声明及附带文章链接：https://boke.wsfnk.com/archives/1243.html
赏
谢谢你请我吃辣条
谢谢你请我吃辣条
如果文章对你有帮助，欢迎点击上方按钮打赏作者
暂无评论