PVE 踩坑笔记：Ceph RBD 盘在 PVE 里创建正常，VM 读写随机卡顿、偶发 IO 超时

一、故障表现

• Ceph 集群健康状态 HEALTH_OK，PG 状态全部 active+clean，无 degraded、peering
• PVE Web 面板可以正常新建 RBD 磁盘、创建快照、迁移虚拟机
• 虚拟机内业务随机卡顿，数据库、中间件偶发 IO 超时
• Ceph 整体监控看总 IOPS、带宽占用不高，没有打满集群上限
• 卡顿没有固定规律，有时连续几分钟正常，突然抖动一次
• 重启虚拟机短暂缓解，一段时间后复现；迁移到其他节点现象依旧

典型特征：Ceph 大集群状态正常，但单个 RBD 镜像 IO 延迟抖动，属于 Ceph+PVE 组合里很隐蔽的 IO 类问题。

二、原理简单说明

PVE 中虚拟机使用 RBD 磁盘，本质是 QEMU 作为 Ceph 客户端，通过 librbd 访问远端 Ceph 块存储。 Ceph 集群整体健康，只代表 OSD、PG 层面没有故障。 单个 RBD 镜像的性能，还受这些因素影响：RBD 镜像的块大小、特征功能（features）、镜像深度、OSD 的后端盘负载、Ceph 客户端配置、QEMU 缓存模式、RBD 的对象分布。 比如开启了不兼容的 RBD 特性、对象分布集中在少数几块 OSD 上，就会出现 “集群闲，单个盘卡” 的现象。

三、排查顺序

1. 先确认 Ceph 集群基础状态

ceph -s
ceph health detail

1. 查看 Ceph OSD 单独负载，定位是否存在热点 OSD

ceph osd perf

重点看每个 OSD 的 latency，个别 OSD 延迟明显高于其他就是热点。

1. 查看虚拟机对应的 RBD 镜像信息

# 替换pool名称、镜像名
rbd info rbd/vm-100-disk-0

1. 在宿主机侧查看 QEMU 对应的 RBD 客户端 IO 统计

# 查看rbd性能统计
rbd perf image stats rbd/vm-100-disk-0

1. 进入虚拟机内部观察磁盘延迟

# Linux虚拟机
iostat -x 1

重点看 await 指标，await 持续偏高就是 IO 链路存在延迟。

四、分场景修复方案

场景 1：RBD 镜像开启过多特性，部分特性带来额外开销

新版本 Ceph 默认给 RBD 镜像开启很多 feature，比如 fast-diff、object-map、journal 等。 object-map、fast-diff 对快照很友好，但会增加写入放大，高随机写场景下延迟抖动明显。

查看当前特性：

rbd info rbd/vm-100-disk-0

⚠️ 修改特性需要先关机虚拟机，并且部分特性开启后无法直接关闭，新建镜像时指定更稳妥。

新建低延迟业务镜像示例（精简特性）：

rbd create rbd/vm-100-disk-0 --size 32G --image-feature layering

只保留 layering，关闭 object-map、fast-diff 等。适合数据库这类低延迟优先业务。

场景 2：OSD 热点，多个高 IO 镜像落在同一组 OSD

Ceph 的 CRUSH 规则可能把多个业务盘映射到相同 OSD，集群总负载不高，但局部 OSD 被打满。

排查：

rbd map rbd/vm-100-disk-0
rbd showmapped
ceph osd map rbd vm-100-disk-0

观察该镜像的 PG 落在哪些 OSD 上。 处理方案：

1. 调整 CRUSH 规则，拆分业务到不同存储池；
2. 把高 IO 业务分散到不同存储池；
3. 混合盘集群（SSD+HDD）确认业务池对应的 CRUSH 规则是否正确走 SSD。

场景 3：QEMU 缓存模式搭配 RBD 不合理

很多人 Ceph 环境下还沿用本地磁盘的 writeback 缓存，容易出现延迟波动；数据库类业务风险更高。

• cache=none：QEMU 不做缓存，IO 直接透传给 Ceph，延迟更稳定，推荐数据库；
• cache=writeback：主机内存缓存，性能好，但断电有丢数据风险；
• cache=writethrough：一致性强，性能差，Ceph 环境一般不推荐。

修改方式：关闭 VM，在硬件磁盘选项修改缓存设置。

场景 4：Ceph 客户端配置缺少优化参数

PVE 节点作为 Ceph 客户端，/etc/ceph/ceph.conf 缺少调整项，默认参数对高随机写不友好。 常用客户端侧优化（根据硬件酌情添加）：

[client]
rbd cache = true
rbd cache size = 67108864
rbd cache max dirty = 33554432

注意 rbd cache 是客户端缓存，和 QEMU 缓存是两层，不要叠加乱配。

场景 5：存储池 PG 数量规划不合理

PG 太少：容易热点；PG 太多：Ceph 内部元数据开销变大，CPU 上涨带来延迟。 通用经验：单块 OSD PG 数量控制在 100~200 区间。 如果 PG 数量不合理，需要新建存储池，迁移 RBD 镜像到新池。

场景 6：Ceph 后台任务干扰（scrub、deep-scrub）

Ceph 定期做清洗、深度清洗，会读取 PG 数据，占用 OSDIO，造成业务抖动。

ceph osd dump | grep scrub

处理：调整 scrub 时间窗口，避开业务高峰，调低清洗并发。

ceph config set osd osd_scrub_begin_hour 23
ceph config set osd osd_scrub_end_hour 5

五、验证修复

调整完成后持续观察：

ceph osd perf
iostat -x 5

OSD 延迟、虚拟机内 await 回落稳定，业务不再随机超时即修复完成。

六、高频踩坑点

1. 只看 Ceph 集群总状态 HEALTH_OK，忽略单个 OSD 热点、单镜像延迟；
2. 所有 RBD 镜像统一使用默认全部开启特性，数据库业务被 fast-diff、object-map 拖累；
3. Ceph 环境下 QEMU 缓存随意设置，数据库业务使用 writeback，兼顾不到稳定性；
4. 混合存储集群，业务池 CRUSH 规则写错，业务跑在机械盘上自己不知道；
5. 忽略 scrub 定时清洗，业务白天随机卡顿，找不到定时触发规律。