开篇场景

"想象你是一名急诊室医生，面对一个突发心脏骤停的病人：

• 快速诊断：心电图识别心律失常（集群健康状态）
• 精准施救：除颤仪恢复心跳（PG修复命令）
• 术后监护：持续监测生命体征（性能调优）
  Ceph集群的故障排查同样需要这样的系统性思维。本文将为你提供一份覆盖90%生产问题的『急救手册』。

第一部分：集群健康诊断（基础篇）

1. 集群健康状态解析

HEALTH_WARN: 5 slow ops, 1 osds down
PG_AVAILABILITY: Reduced data availability (12 PGs stale)
PG_DEGRADED: Degraded data redundancy (24 PGs degraded)

关键状态解读：

2. 十二大高频故障场景

场景1：OSD Down（快递员罢工）

现象：

HEALTH_WARN: 1 osds down

排查流程：

1. 定位故障OSD：

ceph osd tree | grep down

2. 检查物理状态：

ssh  systemctl status ceph-osd@

3. 常见原因：

• 硬盘故障（查看dmesg | grep error）
• 网络中断（ping ）
• 内存泄漏（ceph daemon osd. heap stats）

修复方案：

# 尝试重启OSD
systemctl restart ceph-osd@

# 若硬盘损坏，更换后重新加入集群
ceph osd crush reweight osd. 0  # 临时移出
ceph osd crush reweight osd. 1.0  # 修复后恢复

场景2：PG不一致（账本对不上）

现象：

HEALTH_ERR: 24 pgs inconsistent

修复步骤：

1. 识别问题PG：

ceph pg dump | grep inconsistent

2. 触发修复：

ceph pg repair 

3. 深度检查：

ceph daemon osd. scrub 

预防措施：

# 调整Scrub周期
ceph config set osd osd_scrub_min_interval 86400  # 最小间隔1天
ceph config set osd osd_scrub_max_interval 604800 # 最大间隔7天

第二部分：性能瓶颈定位（进阶篇）

3. 性能问题黄金检查点

场景3：客户端写入卡顿（高速公路堵车）

现象：

• 客户端写入延迟从1ms飙升到500ms
• ceph osd perf显示多个OSD op队列堆积

排查步骤：

1. 定位慢OSD：

ceph osd perf | sort -k3 -n

2. 分析磁盘IO：

iostat -x 1  # 关注%util和await

3. 调整参数：

# 增加OSD队列深度
ceph config set osd osd_op_queue mclock_scheduler
ceph config set osd osd_op_num_threads_per_shard 4

场景4：元数据操作缓慢（图书馆检索卡顿）

优化方案：

1. 分离元数据池：

ceph osd pool create metadata_pool 64 64 replicated_rule
ceph fs new myfs metadata_pool data_pool

2. 启用SSD加速：

ceph osd crush class create ssd
ceph osd crush set-device-class ssd osd.0 osd.1
ceph osd pool set metadata_pool crush_rule ssd_rule

场景5：PG卡在“stale”状态（交通瘫痪）

现象：

HEALTH_WARN: 12 pgs stale

背景：

• PG的主OSD无法与其他副本通信，导致元数据更新停滞
• 类似交通信号灯故障导致路口瘫痪

排查流程：

1. 定位卡住的PG：

ceph pg dump_stuck stale

2. 检查OSD状态：

ceph osd tree | grep 

3. 强制重建PG：

ceph pg force_create_pg 

预防措施：

• 确保Monitor节点高可用（至少3台）
• 配置合理的网络心跳检测：

ceph config set osd osd_heartbeat_interval 10

场景6：认证失败（门禁系统故障）

现象：

2023-09-01 12:00:00.000 0x7f3a5bfff700 -1 auth: unable to find a keyring on /etc/ceph/ceph.client.admin.keyring

排查流程：

1. 检查密钥文件权限：

ls -l /etc/ceph/ceph.client.admin.keyring
# 正确权限应为600

2. 重新生成密钥：

ceph auth get-or-create client.admin mon 'allow *' osd 'allow *' -o /etc/ceph/ceph.client.admin.keyring

3. 验证认证：

ceph -s --keyring /etc/ceph/ceph.client.admin.keyring

场景7：集群容量不足（仓库爆满）

现象：

HEALTH_WARN: near full osd(s)

紧急处理：

1. 快速定位满盘OSD：

ceph osd df | sort -nk 8

2. 临时扩容：

ceph osd crush reweight osd.  # 降低权重转移数据

3. 长期方案：

• 添加新OSD节点
• 启用EC纠删码（节省30%空间）

ceph osd pool create ec_pool 64 64 erasure

场景8：时钟不同步（时间错乱）

现象：

HEALTH_WARN: clock skew detected on mon.node1

修复步骤：

1. 强制同步时钟：

sudo chronyc -a makestep

2. 检查NTP服务状态：

chronyc tracking

3. 配置NTP严格同步：

sudo timedatectl set-ntp true
sudo systemctl restart chronyd

场景9：客户端兼容性问题（方言不通）

现象：

librados: client vs cluster running divergent versions

解决方案：

1. 检查版本兼容性矩阵：

2. 升级客户端库：

sudo apt install librbd1=16.2.0-0ubuntu1

3. 降级集群功能（临时方案）：

ceph osd set-require-min-compat-client jewel

场景10：RGW配置错误（快递拒收）

现象：

rgw: failed to init store

排查流程：

1. 检查配置文件：

grep ^rgw /etc/ceph/ceph.conf

2. 重建RGW元数据索引：

radosgw-admin metadata list
radosgw-admin metadata rm --key=

3. 重启服务：

systemctl restart ceph-radosgw@rgw.$(hostname)

场景11：元数据损坏（图书馆目录丢失）

现象：

HEALTH_ERR: 1 filesystem metadata damage

修复步骤：

1. 进入救援模式：

cephfs-journal-tool --rank=0 journal reset

2. 重建元数据池：

ceph osd pool create new_metadata 64 64
ceph fs reset myfs --yes-i-really-mean-it
ceph fs new myfs new_metadata data_pool

3. 恢复备份：

rados -p new_metadata put mds0_metadata backup.bin

场景12：缓存失效（快递站断电）

现象：

bluestore_cache_autotune: failed to adjust cache size

优化方案：

1. 手动调整缓存比例：

ceph config set osd bluestore_cache_ratio 0.4
ceph config set osd bluestore_cache_autotune false

2. 监控缓存命中率：

ceph daemon osd.0 perf dump | grep cache

3. 升级硬件：

• 为OSD节点添加NVMe缓存盘
• 扩容内存至256GB以上

第三部分：灾难恢复（专家篇）

4. 重大故障应急方案

场景13：Monitor脑裂（失去集群大脑）

现象：

• 多个Monitor节点声称自己是Leader
• 所有Ceph命令返回HEALTH_ERR

恢复步骤：

1. 强制选举新Leader：

ceph-mon --cluster  --setuser ceph --setgroup ceph -i  --inject-monmap monmap

2. 重建Monitor集群：

# 备份原有数据
cp /var/lib/ceph/mon/mon.*/store.db /backup/
# 初始化新Monitor
ceph-mon --mkfs -i  --monmap monmap --keyring /etc/ceph/ceph.mon.keyring

场景13：全集群数据损坏（核弹级灾难）

备份恢复流程：

1. 全量备份：

ceph osd pool get  all > pool_metadata.txt
rados export  > pool_backup.bin

2. 灾难恢复：

ceph osd pool create  
rados import pool_backup.bin -p 
ceph osd pool set    -i pool_metadata.txt

第四部分：专项工具集

5. 运维工具箱

工具1：Ceph自带诊断命令

工具2：外部监控集成

Prometheus监控配置：

scrape_configs:
  - job_name: 'ceph'
    static_configs:
      - targets: ['ceph-mon:9283']

Grafana看板指标：

• 集群容量趋势图
• OSD读写延迟热力图
• PG状态分布环形图

工具3：日志分析神器

ELK日志分析规则：

filter {
  if "cluster" in [tags] {
    grok {
      match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:level} %{DATA:component} %{GREEDYDATA:msg}" }
    }
  }
}

第五部分：经典案例复盘

案例1：某视频平台雪崩事故

时间线：

• 00:00 流量洪峰导致OSD批量过载
• 00:05 多个PG进入degraded状态
• 00:20 客户端写入超时触发级联故障

根本原因：

• OSD队列深度默认值过低（原值500，需调至2000）
• 未配置QoS限速

改进方案：

# 调整OSD队列
ceph config set osd osd_op_queue_mclock_max_capacity 2000
# 启用客户端QoS
ceph tell osd.* injectargs '--osd_client_message_cap 1000'

案例2：银行数据静默损坏

现象：

• 业务系统读取到错误数据
• CRC校验失败但Scrub未报告错误

排查工具：

rados list-inconsistent-pg   # 主动触发深度检查
rados list-inconsistent-obj  # 定位损坏对象

修复技术：

# 从副本重建数据
ceph pg repair 
# 启用端到端校验
ceph osd pool set  checksum_type crc32c

第六部分：日常维护黄金法则

6. 运维Checklist

7. 自动化运维脚本示例

健康检查脚本：

#!/bin/bash
STATUS=$(ceph health)
if [[ $STATUS != "HEALTH_OK" ]]; then
  echo "Ceph cluster is unhealthy: $STATUS" | mail -s "Ceph Alert" admin@example.com
  ceph crash ls >> /var/log/ceph_alert.log
fi

总结

通过这十二式故障排查法，你将能：

1. 快速定位：5分钟内识别90%的常见问题
2. 精准修复：根据场景选择最优解决方案
3. 防患未然：通过监控和Checklist避免故障

附录：运维黄金口诀

一查健康二看PG，三验网络四校时  
五清缓存六扩容，七修元数据八鉴权  
九检版本十日志，十一备份十二灾  
日常巡检勤记录，故障来临心不慌

下篇预告：
《第六篇：Ceph与云原生——K8s存储的终极方案》将揭秘：

• Rook架构如何实现无缝集成
• 动态存储供给的魔法原理
• 生产环境性能调优全攻略