企业官网建设流程全解析

Ceph 的 scrubbing 和 deep-scrubbing 分别是什么？如何调整其时间窗口避免影响业务？

# 要作用是校验副本的一致性，校验失败后会通过正常的数据进行数据的修复• scrubbing：轻量扫描 PG 内对象元数据（对象大小、属性），每日一次 • deep-scrubbing：读取数据并校验 checksum，每周一次，对 IO 影响较大。

如何在不重启 Ceph 集群的情况下，优雅地移除一个 OSD（如硬件下架）？

# 1.先将该osd打上out的标签，打上标签之后会出发osd的自动迁移，以及不对改osd节点读写请求ceph osd out<id># 2.等迁移结束，删除cursh map中的节点信息ceph# 3.删除认证密钥# 4.删除改osd节点ceph osd purge<id>--yes-i-really-mean-it

Ceph 集群出现 OSD 故障或慢请求，你会如何诊断？请列出排查思路和常用命令。

# 1.检查集群osd状态（ceph osd tree）# 2.查看慢请求日志（ceph daemon osd.<id> perf dump）/内部日志，json格式，展示接口交互信息、回写 (Write-Back) 限流信息、# 3.分析磁盘 IO（iostat -x 1）# 4.检查网络丢包/延迟（ping, ethtool，ceph osd perf ）# 5.Ceph服务日志。 /journalctl -u ceph-osd@

你对 Ceph 的 rebalance 触发的网络/磁盘压力有何应对策略？

# osd状态变化是自动触发，重新分布数据副本，保证数据均匀的分布在每个节点上# 限制 recovery 带宽：osd max backfills=1, osd recovery max active=3。# 动态调整 QoS：ceph tell osd.* injectargs --osd-max-backfills 1。 (用于对不同类型的 IO 请求进行优先级管理和资源分配。)# 使用 mclock 调度器（新版本）：设置 osd_mclock_profile = high_client_ops 提升用户 IO 优先级。

你在 Ceph 集群扩容（增加 OSD）时，会执行哪些步骤？如何保证扩容不影响线上业务？

Ceph 中如何做跨机房级别的数据副本放置策略？请用 CRUSH map 示例说明。

创建bucket时添加一条规则，保证副本不落在同一个room中即可

#创建自定义 bucket（如 rack, room），定义 rule：rule cross_room{typereplicated steps: - chooseleaf firstn0typeroom - emit}保证两个副本落在不同 room。 管理room room创建 room，比如ceph osd crush add-bucket room1 room。 然后将 rack 或host加入 room，例如ceph osd crush move rack1root=defaultroom=room1。 最后可以用ceph osd crush tree查看结构是否正确。

集群状态卡在 HEALTH_WARN，提示 slow ops，你会怎么排查？

现象：大量操作执行超时没有完成，一般是集群的io路径有瓶颈 排查思路： 使用 ceph daemon osd.<id>ops查看哪些操作缓慢-->检查OSD 磁盘或网络延迟（iostat、ping、ceph osd perf） 也有可能是osd节点的数据分布不均，导致某个osd节点压力过大，可以检查下pg数是否合理，使用ceph osd reweight调节权重

一个 OSD 突然 down 了，如何恢复其上 PG 到其他 OSD？

# 1.如果osd节点确认无法恢复，先执行cepg osd out 命令打上out标签，移出集群（自动进行数据迁移）-->再把这个坏掉的osd节点彻底移出即可# 2.如果osd节点down有限尝试重启当前osd节点，看能不能恢复，检查是否是网络原因

集群出现 PGs stuck inactive 或 PGs stuck unclean，如何处理？

# stuck inactive ：原因：所有的osd节点都不可用/mon无法确定pg的正确状态。可能的原因有多个 OSD 同时宕机、网络分区导致副本无法通信、MON 集群故障等。检查 MON 是否能正常选举，网络是否分区。1.首先用ceph pg<pg_id>query查看该PG的副本OSD状态，确认是否有OSD down 或网络不通。如果OSD宕机，尝试重启OSD服务；若OSD无法恢复，标记其out，让集群自动迁移副本。2.若OSD都正常，检查MON集群状态是否健康，修复MON故障。同时查看OSD日志和集群网络，排除网络分区问题。等所有副本OSD恢复通信后，PG会自动恢复 active 状态。处理过程中可以用ceph -w实时监控状态变化。# stuck unclean：表示PG长时间处于不清洁状态，通常是因为数据副本不完整或存在错误。可能是部分OSD宕机导致副本缺失、数据恢复失败、PG 映射错误等原因。这种情况下，集群会持续尝试修复，但如果问题没解决就会一直 stuck。需要先通过 ceph pg<pg_id>query 看具体副本情况，再针对性处理，比如恢复宕机 OSD、检查数据损坏等。

检查 MON 是否能正常选举，网络是否分区。

# 主要是资源控制手段• 调低 osd_max_backfills（每个 OSD 并发回填数）。 • 调低 osd_recovery_max_active（并发恢复请求数）。 • 设置 osd_recovery_sleep（在恢复操作之前主动睡眠）。 • 使用 mClock 调度器，设置 osd_mclock_profile=high_client_ops 提高客户端 IO 优先级。

Ceph 集群出现 PG 状态 inconsistent 或 stale，你会怎么处理？

• inconsistent：ceph pg repair<pgid>触发修复（自动对比和修复差异）。若无效，手动选择权威副本 ceph pg map<pgid>提取对象，或回滚快照。 inconsistent 表示pg的副本数据不一致现象/一般原因是磁盘损坏、网络问题、osd崩溃导致 • stale：MON 与 OSD 失联，检查网络、OSD 进程，重启 OSD 或回填。若 MON 挂掉，修复 MON 存储后，可能需要 ceph monsyncforce。 stale 表示mon长时间没有收到pg对应主osd的心跳回复，无法确认osd的状态

如果 MON 磁盘满导致集群不可用，但仍有部分 MON 存活，如何紧急恢复？

先将磁盘满的mon停掉，此时剩下的两台mon会选举出新的主mon，清理磁盘空间后启动当前节点

客户端挂载 RBD 出现 timeout 或 lock 冲突（如多个虚拟机争抢同一 RBD），你如何定位和解决？

当一个虚拟机挂在了RBD镜像，RBD会自动为镜像加锁，这样其他虚拟机就无法挂载这个镜像。 • lock 冲突：rbd lock list<pool>/<image>查看锁持有人，强制释放：rbd lock remove<pool>/<image>"<lock_id>""<client>"。 • timeout：检查 ceph osd perf 是否存在 OSD 延迟，调整客户端 rbd_client_timeout，或排查网络丢包。

请举例说明你曾经处理过的一次 Ceph 夜间故障，你当时的响应流程、解决时长、后续改进措施。

（此题为开放性经历题，参考如下示例） • 故障：某凌晨2点，一个 OSD 所在盘 smart 报错，导致该 OSD 频繁 flapping，集群 PG 降级。 • 响应：2:10 收到短信告警，登录检查 ceph osd tree，发现 OSD.12 周期 down/up，磁盘 IO 错误。 • 操作：立即强制 out 该 OSD ceph osd out12，等待数据迁移（约30分钟）。同时准备更换硬盘。 • 解决时长：1 小时完成 out+迁移，天亮后更换硬盘。 • 改进：增加磁盘 smart 监控，并设置 osd flapping 自动 kill。

凌晨 3 点，你收到 Ceph 集群报警：“20% OSD 标记为 down”、“MON 时钟偏移过大”。你会如何按优先级处理？

1. 确认 MON 时钟偏移：ceph health detail 查看偏移量，若超过0.2s 可能导致 quorum 失联。临时启动 NTP 或 chrony 同步，若某个 MON 偏差极大，可重启该 MON。2. 处理 OSD down：先判断是否为网络分区（检查心跳网络），如果是单机多 OSD down，可能是机柜掉电或交换机故障，立即联系机房值班。3. 部分 OSD down 但副本仍足够（仍有其他副本），可等待自动恢复；若数据面临丢失风险，停止业务写入，尝试强制 up 某些 OSD。