SStorpath
闯关预计 40 分钟

闯关：对象存储 5xx 激增

监控报 RGW 错误率飙升，但 Ceph 集群显示 HEALTH_OK。

学完这节你能做到

  • 在集群健康的情况下定位网关层故障
  • 把 RGW 的报错映射到 index 池与分片问题
  • 给出既能救急又能治本的处置方案

场景

周一上午 10:30，监控告警：

[P1] RGW 5xx 错误率 12.4%（阈值 1%），持续 8 分钟

业务方同步反馈：备份任务大量失败，报 503 SlowDown；但另一个组说他们的图片上传一切正常。

你敲 ceph -s，返回 HEALTH_OK。

✓集群健康但业务报错，说明什么

HEALTH_OK 只说明 RADOS 层没问题。RGW 是架在 RADOS 之上的网关，它自己的瓶颈（index 池热点、bucket 分片、网关并发、LB 配置）不会体现在 ceph -s 里。

这类"集群健康但业务报错"的场景，排查重点在网关层和它依赖的元数据池，而不是 OSD。

root@ceph-node1
目标 0/6
  1. 1.确认 RGW 网关侧的错误与积压情况
  2. 2.定位到出问题的 bucket，看它的对象数与分片数
  3. 3.对照一个正常的 bucket，验证判断
  4. 4.确认 index 池的冗余方式与所在介质
  5. 5.确认默认规则选中的是哪一类设备
  6. 6.确认集群里是否存在混合介质
模拟终端：RGW 5xx 激增，但 ceph -s 显示 HEALTH_OK。
部分业务正常、部分业务失败 —— 这个差异是重要线索。
输入 goals 看目标，hint 要提示。
[root@ceph-node1 ~]#
help 查看用法 · goals 看目标 · hint 要提示 · ↑↓ 翻历史

复盘

结论：backup-prod bucket 有 4.13 亿个对象但仅 11 个索引分片（平均每片 3750 万对象），且 buckets.index 池未限定 device class，部分索引 PG 落在 HDD 上（延迟 400ms 量级）。索引读写成为瓶颈，RGW 请求队列打满（qlen = qactive = 1024），新请求被拒绝返回 503 SlowDown。

images-prod 因分片充足（128 片 / 841 万对象）未受影响——这解释了"部分业务正常"的现象。

处置分两步：

# ── 救急（分钟级）──
# 1. 让备份任务降低并发，先把队列压力降下来
#    （沟通比命令更有效：告诉业务方并发从 64 降到 8）

# 2. 临时扩大 RGW 请求队列与线程数，缓解排队
ceph config set client.rgw rgw_max_req_queue_len 4096
ceph config set client.rgw rgw_thread_pool_size 1024
ceph orch restart rgw.s3

# ── 治本（需要窗口）──
# 3. 把 index 池限定到 SSD —— 这是最高优先级的一步
ceph osd crush rule create-replicated ssd-rule default host ssd
ceph osd pool set default.rgw.buckets.index crush_rule ssd-rule

# 4. 对 backup-prod 重新分片（会阻塞该 bucket 写入，必须选窗口）
radosgw-admin bucket reshard --bucket=backup-prod --num-shards=4096

# 5. 修正全局默认值，避免新 bucket 重蹈覆辙
ceph config set client.rgw rgw_override_bucket_index_max_shards 128
!reshard 4 亿对象的代价必须提前说清

对一个 4 亿对象的 bucket 做 reshard，期间该 bucket 的写入会被阻塞，耗时可能长达数小时。

执行前必须：

  1. 和业务方约定停写窗口，而不是"顺手做一下"
  2. 先确认 index 池已经在 SSD 上（否则 reshard 本身会慢得离谱）
  3. 评估是否更适合拆成多个 bucket —— 单 bucket 4 亿对象本身就是设计问题

最好的解法是这个 bucket 当初创建时就把分片设够。 这也是为什么"预计存多少对象"必须在设计阶段就问清楚。

×混闪集群里最容易漏的一件事

只要集群里有 HDD，所有元数据类的池都必须显式限定 device class：

  • *.rgw.buckets.index
  • *.rgw.meta、*.rgw.log
  • cephfs.*.meta
  • RBD 池的元数据（如果单独分池）

默认的 replicated_rule 不限定介质，PG 会随机落到 HDD 上。这个隐患在集群刚建好、数据量小的时候完全看不出来，等到规模上来才集中爆发——正如这一关的场景。

检查点单选

ceph -s 显示 HEALTH_OK，但 RGW 大量返回 503。这说明什么？

检查点单选

一个 bucket 有 4 亿对象、11 个索引分片。按规划口径，分片数应该是多少量级？

检查点多选

混闪集群里，下面哪些池必须显式限定 device class 到 SSD？（多选）

这一关的落点

  • ceph -s 只覆盖 RADOS 层，网关层问题要用 ceph daemon rgw.<name> perf dump 看
  • qlen = qactive 说明请求队列打满，客户端会收到 503 SlowDown
  • 部分 bucket 正常、部分异常 → 用 bucket stats 做对照，快速锁定
  • 索引分片按每片约 10 万对象规划，建 bucket 时设够，事后 reshard 要阻塞写入
  • 混闪集群里所有元数据池都必须显式限定 device class
  • 处置分救急（降并发、扩队列）和治本（换介质、reshard、改默认值）两层

延伸资料

  • ·k8s-in-actionstorage/cephadm/5-deploy-rgw.md
  • ·k8s-in-actionstorage/rook/rgw/README.md
下一课：Ceph 性能调优与压测 →