当前位置： 首页 > news >正文

Ceph集群故障处理 - PG不一致修复

news 2025/5/11 7:17:02

Ceph集群故障处理 - PG不一致修复

    • 目录
    • 故障现象
    • 故障分析
    • 故障定位
    • 修复过程
    • 磁盘状态检查
    • OSD存储结构检查
    • 修复分析
    • 故障总结
      • 问题原因
      • 修复方法
      • 后续建议
      • 经验教训
      • 最佳实践
    • 参考资料

# ceph -v
ceph version 14.2.22

目录

  • 故障现象
  • 故障分析
  • 故障定位
  • 修复过程
  • 磁盘状态检查
  • OSD存储结构检查
  • 修复分析
  • 故障总结
  • 参考资料

故障现象

通过ceph -s命令发现集群处于HEALTH_ERR状态，显示存在scrub错误和数据不一致问题：

# ceph -scluster:id:     xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxhealth: HEALTH_ERR1 scrub errorsPossible data damage: 1 pg inconsistent

从输出可以看出：

  • 集群有1个scrub错误
  • 有可能的数据损坏：1个PG处于不一致状态
  • 另有1个PG正在进行深度清洗(deep scrubbing)

故障分析

使用ceph health detail命令获取更详细的错误信息：

# ceph health detail
HEALTH_ERR 1 scrub errors; Possible data damage: 1 pg inconsistent
OSD_SCRUB_ERRORS 1 scrub errors
PG_DAMAGED Possible data damage: 1 pg inconsistentpg 2.8d8 is active+clean+inconsistent, acting [159,79,609,286,11,431,355,398,490,210]

从上述输出可以看出：

  • 有1个PG处于不一致状态：2.8d8
  • 该PG上的acting OSD列表包括10个OSD：[159,79,609,286,11,431,355,398,490,210]
  • 虽然PG状态为active+clean+inconsistent，表示它可以提供读写服务，但存在数据一致性问题

注意：inconsistent标志意味着在scrub或deep-scrub过程中，Ceph发现了数据不一致的问题。这可能是由于磁盘故障、I/O错误或其他硬件问题导致的。

故障定位

找到主OSD（159）的位置信息：

# ceph osd find 159
{"osd": 159,"addrs": {"addrvec": [{"type": "v2","addr": "10.x.x.x:6950","nonce": xxxxx},{"type": "v1","addr": "10.x.x.x:6951","nonce": xxxxx}]},"osd_fsid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","host": "osd-host03","crush_location": {"host": "osd-host03","root": "default"}
}

OSD.159位于主机osd-host03上，这是PG 2.8d8的主OSD。在Ceph的PG架构中，主OSD负责协调该PG上的所有操作，包括读取、写入和scrub操作。

修复过程

确认问题后，执行PG修复命令：

# ceph pg repair 2.8d8
instructing pg 2.8d8s0 on osd.159 to repair

ceph pg repair命令会指示主OSD尝试修复PG中的数据不一致问题。修复过程中，Ceph会从健康的副本中恢复数据。

查看OSD日志以确认修复进展：

# tail -n 50 /var/log/ceph/ceph-osd.159.log2025-05-10 21:33:43.258 xxxxxxxxx  0 log_channel(cluster) log [DBG] : 2.8d8 repair starts
2025-05-10 21:35:03.066 xxxxxxxxx -1 log_channel(cluster) log [ERR] : 2.8d8 shard 398(7) soid 2:xxxxxxxx:::xxxxxxxxxx.xxxxxxxx:head : candidate had a read error
2025-05-10 21:35:43.607 xxxxxxxxx -1 log_channel(cluster) log [ERR] : 2.8d8s0 repair 0 missing, 1 inconsistent objects
2025-05-10 21:35:43.608 xxxxxxxxx -1 log_channel(cluster) log [ERR] : 2.8d8 repair 1 errors, 1 fixed

从日志可以清楚地看到：

  • 修复从21:33:43开始
  • 在21:35:03，发现了问题所在：OSD.398（acting列表中的第7个OSD，即shard 398(7)）上的对象出现读取错误
  • 在21:35:43，修复完成，报告修复了1个不一致对象

磁盘状态检查

通过日志发现分片398(7)上存在读取错误，需要进一步检查OSD.398使用的磁盘：

# smartctl -a /dev/sdah
smartctl 7.0 2018-12-30 r4883 [x86_64-linux-3.10.0-1160.119.1.el7.x86_64] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org=== START OF INFORMATION SECTION ===
Device Model:     WUH721816ALE6L4
Serial Number:    XXXXXXXXX
LU WWN Device Id: 5 000cca XXXXXXXXX
Add. Product Id:  XXXXXX
Firmware Version: PCGAW270
User Capacity:    16,000,900,661,248 bytes [16.0 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-4 (unknown minor revision code: 0x009c)
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sat May 10 22:19:33 2025 CST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSEDGeneral SMART Values:
Offline data collection status:  (0x82) Offline data collection activitywas completed without error.Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completedwithout error or no self-test has ever been run.
Total time to complete Offline 
data collection:                (  101) seconds.SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE1 Raw_Read_Error_Rate     0x000b   100   100   001    Pre-fail  Always       -       02 Throughput_Performance  0x0005   136   136   054    Pre-fail  Offline      -       963 Spin_Up_Time            0x0007   083   083   001    Pre-fail  Always       -       336 (Average 339)4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       365 Reallocated_Sector_Ct   0x0033   100   100   001    Pre-fail  Always       -       07 Seek_Error_Rate         0x000b   100   100   001    Pre-fail  Always       -       08 Seek_Time_Performance   0x0005   140   140   020    Pre-fail  Offline      -       159 Power_On_Hours          0x0012   096   096   000    Old_age   Always       -       3406910 Spin_Retry_Count        0x0013   100   100   001    Pre-fail  Always       -       012 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       3622 Unknown_Attribute       0x0023   100   100   025    Pre-fail  Always       -       100
184 End-to-End_Error        0x0033   100   100   097    Pre-fail  Always       -       0
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       65536
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       1455
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       1455
194 Temperature_Celsius     0x0002   063   063   000    Old_age   Always       -       32 (Min/Max 17/49)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       16
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   100   100   000    Old_age   Always       -       0
241 Total_LBAs_Written      0x0012   100   100   000    Old_age   Always       -       68388904427
242 Total_LBAs_Read         0x0012   100   100   000    Old_age   Always       -       4664543043SMART Error Log Version: 1
ATA Error Count: 2Error 2 occurred at disk power-on lifetime: 34068 hours (1419 days + 12 hours)When the command that caused the error occurred, the device was active or idle.After command completion occurred, registers were:ER ST SC SN CL CH DH-- -- -- -- -- -- --40 43 00 00 00 00 00  Error: UNC at LBA = 0x00000000 = 0Commands leading to the command that caused the error were:CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name-- -- -- -- -- -- -- --  ----------------  --------------------60 00 00 80 3f 91 40 00   2d+01:31:42.070  READ FPDMA QUEUED61 00 08 80 34 70 40 00   2d+01:31:39.514  WRITE FPDMA QUEUED60 00 00 80 36 97 40 00   2d+01:31:39.463  READ FPDMA QUEUED60 00 00 00 8a f9 40 00   2d+01:31:39.455  READ FPDMA QUEUED60 00 00 80 c7 41 40 00   2d+01:31:39.450  READ FPDMA QUEUEDError 1 occurred at disk power-on lifetime: 34068 hours (1419 days + 12 hours)When the command that caused the error occurred, the device was active or idle.

磁盘检查结果分析：

关键指标值解释
整体健康评估PASSED磁盘自我评估仍为通过状态
Current_Pending_Sector16有16个扇区存在读取问题
UNC错误2个不可纠正的读取错误
Power_On_Hours34069运行时间约3.9年
Command_Timeout65536出现过命令超时情况

虽然磁盘整体评估为PASSED，但出现的Current_Pending_Sector和UNC错误是严重的预警信号，表明该磁盘已经开始出现物理故障，应当计划更换。

OSD存储结构检查

使用ceph-volume lvm list命令检查OSD.398的存储配置：

===== osd.398 ======[block]       /dev/ceph-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/osd-block-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxblock device              /dev/ceph-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/osd-block-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxblock uuid                XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXXcephx lockbox secret      cluster fsid              xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxcluster name              cephcrush device class        Nonedb device                 /dev/vg_nvme1n1/lv_sdahdb uuid                   XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXXencrypted                 0osd fsid                  xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxosd id                    398osdspec affinity          type                      blockvdo                       0devices                   /dev/sdah[db]          /dev/vg_nvme1n1/lv_sdahblock device              /dev/ceph-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/osd-block-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxblock uuid                XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXXcephx lockbox secret      cluster fsid              xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxcluster name              cephcrush device class        Nonedb device                 /dev/vg_nvme1n1/lv_sdahdb uuid                   XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXXencrypted                 0osd fsid                  xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxosd id                    398osdspec affinity          type                      dbvdo                       0devices                   /dev/nvme1n1

存储配置分析：

  1. OSD.398使用/dev/sdah作为存储设备
  2. 使用NVMe设备(/dev/nvme1n1)上的卷组作为DB设备
  3. 采用了BlueStore存储引擎
  4. 该OSD的数据位于LVM逻辑卷上

修复分析

通过日志分析修复过程：

  1. 2025-05-10 21:33:43 - 修复操作启动（PG 2.8d8）
  2. 2025-05-10 21:35:03 - 发现分片398(7)上的对象出现读取错误
  3. 2025-05-10 21:35:43 - 修复结果统计：0个缺失对象，1个不一致对象
  4. 2025-05-10 21:35:43 - 修复完成：发现1个错误，修复了1个错误

修复是成功的，Ceph能够自动从正常的副本恢复数据。这体现了Ceph的自愈能力，当检测到数据不一致问题时，可以通过repair操作从健康副本恢复数据。

故障总结

问题原因

  • 磁盘故障：PG 2.8d8中存在一个不一致的对象，具体在OSD.398（acting列表中的第7个OSD）上发生了读取错误
  • 磁盘健康状况：SMART检查显示/dev/sdah磁盘存在16个待处理扇区和UNC读取错误
  • 磁盘年龄：磁盘已运行约3.9年，开始出现读取错误
  • 故障模式：这是典型的磁盘扇区读取错误导致的数据不一致问题

修复方法

  • 使用Ceph自愈功能：通过ceph pg repair 2.8d8命令成功修复了不一致的对象
  • 数据恢复：Ceph自动从其他健康副本恢复了正确的数据
  • 修复过程：由主OSD.159协调，确认并修复了OSD.398上的问题对象

后续建议

  1. 磁盘监控：

    • 密切监控OSD.398所在磁盘(/dev/sdah)的健康状态
    • 每周运行一次smartctl检查
    • 配置监控系统报警Current_Pending_Sector值变化

  2. 磁盘更换计划：

    • 考虑尽快更换该磁盘，因为存在扇区错误可能会导致更多数据问题
    • 准备好替换磁盘，并安排合适的维护窗口进行更换

  3. 验证步骤：

    • 运行完整的SMART自检: smartctl -t long /dev/sdah
    • 再次执行deep-scrub验证PG健康: ceph pg deep-scrub 2.8d8
    • 验证集群状态: ceph -s

经验教训

  • 主动监测的重要性：定期执行deep scrub可以及时发现数据不一致问题
  • 修复流程：对于不一致的PG，使用ceph pg repair命令可以高效修复
  • 后续验证：修复后应检查集群状态确认问题已解决
  • 硬件监控：磁盘的Current_Pending_Sector和SMART错误日志是预测硬盘故障的重要指标
  • 冗余设计的价值：正是因为Ceph的多副本设计，才能在单个OSD出现问题时保证数据的完整性

最佳实践

  1. 清洗策略优化：

    • 设置适当的scrub和deep scrub策略
    • 建议工作时间轻负载执行scrub，周末执行deep-scrub
    • 对于大型集群，错开不同OSD的scrub时间

  2. 数据保护：

    • 对于重要数据，考虑增加副本数量或使用纠删码
    • 定期验证备份策略和灾难恢复流程

  3. 硬件管理：

    • 保持硬件设备健康，避免磁盘读写错误
    • 建立硬盘SMART监控系统，及时发现潜在问题
    • 对运行3年以上的硬盘进行更严格的监控
    • 实施预防性替换策略，而不是等到磁盘完全故障

  4. 监控系统增强：

    • 配置自动化监控工具监控SMART属性
    • 设置关键指标的阈值报警
    • 建立磁盘健康评分系统，综合评估磁盘状况

参考资料

  • Ceph PG 状态说明
  • Ceph 数据一致性
  • Ceph 故障排除
  • SMART属性解读
  • Ceph数据修复命令
  • 存储硬盘预测性故障分析
http://www.xdnf.cn/news/377119.html

相关文章：

  • [SV]等待32个instance的某一个信号的pulse，该怎么写？
  • Windows 系统 - Trae 内 终端 无法使用 node (重新配置 nodejs 路径)
  • 青藏高原东北部祁连山地区250m分辨率多年冻土空间分带指数图（2023）
  • AtCoder AT_abc405_d ABC405D - Escape Route
  • 智慧能源大数据平台建设方案（PPT）
  • 数字孪生实战笔记（1）数字孪生的含义、应用及技术体系
  • RPA 浏览器自动化：高效扩展与智能管理的未来
  • SpringBoot学习(上) , SpringBoot项目的创建(IDEA2024版本)
  • 基于阿伦尼斯模型的电池寿命预测：原理、应用与挑战
  • 数据结构：树（树的定义和基本术语）
  • JGL069垃圾填埋场模拟装置试验台
  • 力扣top100 矩阵置零
  • 近日部署跑通的若干多模态模型总结与论文概述
  • clangd与clang-tidy
  • Flutter PIP 插件 ---- 为iOS 重构PipController, Demo界面，更好的体验
  • 优选算法——前缀和
  • Java---StringJoiner 的使用
  • C++11新特性：深入解析decltype关键字及其与auto的区别
  • AI Agent（8）：安全与伦理考量
  • [题解]2023CCPC黑龙江省赛 - Folder
  • 警惕C#版本差异多线程中的foreach陷阱
  • 每日c/c++题 备战蓝桥杯(P2241 统计方形（数据加强版）)
  • （四）YOLO_World-SAM-GraspNet的mujoco抓取仿真（操作记录）
  • C++STL——priority_queue
  • 运算符与表达式 -《Go语言实战指南》
  • IBM BAW（原BPM升级版）使用教程第八讲
  • 研发效率破局之道阅读总结(5)管理文化
  • 17.【.NET 8 实战--孢子记账--从单体到微服务--转向微服务】--微服务基础工具与技术--ELK
  • Springboot之会话技术
  • 关于web3