笙亿网络策划

Ceph存储OSD故障频发怎么办？最新应对策略是什么？

约 14 分钟读完 1 阅
文章导读
针对Ceph存储OSD故障频发的问题，最新应对策略应遵循“预防为主、快速隔离、分级恢复、硬件迭代”的原则。首先，在集群维护或节点宕机重启前，必须优先设置noout、norecover等维护标记位，防止数据盲目重平衡导致雪崩。其次，故障发生后需立即通过ceph health detail和日志定位根因，区分是磁盘坏道、网络延迟还是软件配置问题。对于磁盘损坏，应及时执行ceph pg repair临时
📋 目录
  1. 壹 Ceph OSD 故障运维手册_ceph关机维护-CSDN博客
  2. 贰 Ceph 磁盘损坏现象和解决方法
  3. 叁 ceph osd故障处理
  4. 肆 解决Ceph集群中的故障和性能问题
  5. 伍 FAQ
A A

针对Ceph存储OSD故障频发的问题，最新应对策略应遵循“预防为主、快速隔离、分级恢复、硬件迭代”的原则。首先，在集群维护或节点宕机重启前，必须优先设置noout、norecover等维护标记位，防止数据盲目重平衡导致雪崩。其次，故障发生后需立即通过ceph health detail和日志定位根因，区分是磁盘坏道、网络延迟还是软件配置问题。对于磁盘损坏，应及时执行ceph pg repair临时修复并更换硬件；对于性能瓶颈，可通过调整osd_max_backfills和osd_recovery_sleep参数切换全速或低速恢复模式。同时，建议部署Grafana等监控工具实时追踪IOPS与延迟，并定期升级内核与依赖环境，确保底层系统兼容性，从而从根本上降低OSD故障率。

Ceph OSD 故障运维手册_ceph关机维护-CSDN博客

1、 Ceph集群故障了整体思路 若Ceph 存储集群所有 OSD 节点均宕机,重启后要做的第一件事 —— 重点的事说三遍:先打集群维护标记位!先打集群维护标记位!先打集群维护标记位! 只有这样,才能最大程度保住数据不丢失。同理,存储集群关机前,也务必先打集群维护标记位;待开机后,所有 OSD 均正常运行,再解除标记位。(没经历过机房整体宕机的运维同事,可能真体会不到这几条 “保命操作” 的重要性。) ceph osdsetnoout ceph osdsetnorecover ceph osdsetnobackfill ceph osdsetnorebalance 一键获取完整项目代码bash 1 2 3 4 下面我们分别对这些标记做简单说明 noout: 表示不会将down osd 移除集群. recover: 其主要关注是pg的完整行,作用于有缺失副本的 PG,是主动修复缺失副本的过程. backfill: 关注的是新OSD/新位置的对象同步。只同步到 新加入或重新分配的OSD,而不是所有缺失副本。可以理解为 Recovery 的子集,但只针对新位置 rebalanc: Rebalance是Ceph 根据CRUSH map或OSD 权重调整重新分布PG 的过程。它并不是修复缺失副本,而是 调整数据分布,使每个 OSD 存储负载均衡。 其三者的关系如下: Rebalance→调整PG 位置→触发Backfill→填充新 OSD 数据→可能触发 Recovery(保证副本完整) 完整的集群异常down机处理流程如下图 2、 全速恢复 OR 低速恢复 集群故障后,为尽快恢复业务,建议采用全速恢复模式,可通过调整回填和恢复的 OSD 数量来控制恢复速率。以下是生产环境中建议的配置: # ceph 全速恢复配置ceph configsetglobal osd_max_backfills5ceph configsetglobal osd_recovery_max_active5ceph configsetglobal osd_recovery_sleep0.01 一键获取完整项目代码bash 1 2 3 4 当扩容节点后,为避免影响现有集群的带宽和 IO 性能,可采用低速恢复模式。 # 最低恢复配置ceph configsetglobal osd_max_backfills1ceph configsetglobal osd_recovery_max_active1ceph configsetglobal osd_recovery_sleep0.5 一键获取完整项目代码bash 1 2 3 4 3、 OSD 三道水位线 如果一个osd的数据量接近满容量之前,ceph为了保证原有的数据不丢失会阻止新的数据写入。为此ceph设置了三道水位线。 第一道水位线告警mon（撰于2025年9月8日）

Ceph 磁盘损坏现象和解决方法

1. 磁盘损坏 1.1 现象 工作环境中出现问题的 Ceph 的数据是双备份的,OSD 35 所在的磁盘出现了坏道,表现出来的现象是 ceph 经常会报出存储在 OSD 35 上的 pg 数据不一致,以及报出 scrub error,以下是ceph health detail命令输出新相关信息。 代码语言:javascript AI代码解释 $ ceph health detailOSD_SCRUB_ERRORS31scrub errorsPG_DAMAGEDPossible data damage:5pgs inconsistent pg41.33is active+clean+inconsistent,acting[35,33]pg41.42is active+clean+inconsistent,acting[29,35]pg51.24is active+clean+inconsistent,acting[35,43]pg51.77is active+clean+inconsistent,acting[28,35]pg51.7b is active+clean+inconsistent,acting[35,46] 1.2 数据状态 因为数据只有双备份,ceph 无法确定哪个备份中的数据是可用的,所以此时虽然显示 pg 状态是 active+clean,但有问题的数据其实是不可用的。 1.3 临时解决方法 作为临时的解决方案,可以执行 ceph pg repair 解决,此时由于磁盘坏道造成不可读的数据会拷贝到其他位置。但这不能从根本上解决问题,磁盘损坏会持续报出类似的错误。 代码语言:javascript AI代码解释 $ ceph pg repair41.33$ ceph pg repair41.42$ ceph pg repair51.24$ ceph pg repair51.77$ ceph pg repair51.7b 2. 定位并检查故障磁盘 知道OSD 35 有问题,但我们现在还不知道对应的是具体哪块磁盘。我们可以登录到对应到 OSD服务器上查看 OSD 35 的目录名称,并查看 PVS 的对应关系来解决。 代码语言:javascript AI代码解释 $ ceph osd treeIDCLASSWEIGHTTYPENAMESTATUSREWEIGHTPRI-AFF-1127.09767rootdefault-5127.09767host osd733hdd5.52599osd.35up1.000001.00000 通过这个命令,我们可以知道 OSD.35 是位于 OSD7 这台服务器上。接下来,我们登录到 OSD7 上,并切换为 root 权限。 代码语言:javascript AI代码解释 $ ssh osd7 $ sudo-i 然后进入到 OSD.35 的目录里。 代码语言:javascript AI代码解释 # cd/var/lib/ceph/osd/ceph-35 再来查看 PVS 信息。 代码语言:javascript AI代码解释 # pvs-o+pv_usedPVVGFmt Attr PSize PFree Used/dev/sda5 ubuntu-vg lvm2 a--446.65g0446.65g/dev/sdc ceph-320de131-5f26-48a7-aa64-c7f08f87cd85 lvm2 a--5.46t05.46t（该信息的时间戳是2026年4月5日）

ceph osd故障处理

一、检测OSD故障 当一个OSD出现故障时,Ceph系统通常会提供一些指示来报告故障的发生。管理员可以通过观察日志文件、运行命令或使用Ceph集群监控工具来检测到故障的OSD。以下是一些常见的指示: 1. OSD状态变为“down”:当一个OSD不可用时,Ceph会将其状态标记为“down”。可以通过运行命令`ceph osd tree`来查看OSD的状态。 2. 数据迁移速度变慢:当一个OSD故障时,Ceph会将其上的数据迁移到其他正常的OSD上。这可能导致数据迁移速度变慢,可以通过监控工具观察到这一现象。 3. 数据健康状态异常:Ceph系统会监控数据的完整性和一致性。当一个OSD故障时,可能会导致数据健康状态异常,可以通过运行命令`ceph health detail`来检查数据健康状态。 二、处理OSD故障 一旦检测到OSD故障,系统管理员应该迅速采取措施来处理故障并修复系统。以下是一些常见的OSD故障处理步骤: 1. 确认故障的OSD:首先,管理员需要确认哪个OSD出现了故障。可以通过观察日志文件、运行命令或使用监控工具来确定故障的OSD。 2. 重新启动故障的OSD守护进程:有时,一个OSD可能出现了临时的故障,重新启动OSD守护进程可能可以解决问题。可以使用命令`systemctl restart ceph-osd@`来重新启动故障的OSD。 3. 替换故障的硬件:如果故障的OSD与硬件故障有关,例如硬盘故障,那么管理员可能需要替换故障的硬件。在替换硬件之前,应该先将故障的OSD从Ceph集群中标记为“out”,以防止数据丢失。 4. 从其他OSD恢复数据:当一个OSD故障时,Ceph系统会自动将其上的数据迁移到其他正常的OSD上。一旦故障的OSD修复好了,可以通过运行命令`ceph osd reweight`来重新平衡数据分布。 5. 监控和预防措施:为了更好地处理OSD故障,Ceph系统管理员应该密切监控系统状态并采取预防措施。可以使用Ceph的监控工具来监控OSD的运行状态、数据健康状态和数据迁移速度。此外,定期检查硬件状态和进行备份也是非常重要的。（资料日期为2024年2月1日）

解决Ceph集群中的故障和性能问题

当Ceph集群遇到OSD故障时,我们可以采取以下步骤快速诊断问题并进行修复: 检查Ceph集群状态:使用ceph -s命令检查集群状态,查看是否有OSD出现故障。如果有OSD出现故障,会显示在集群状态中。 查看OSD状态:使用ceph osd tree命令查看OSD的状态,包括OSD的ID、主机名、状态等信息。确定故障的OSD所在的节点。 检查故障的OSD:登录到故障的OSD所在的节点,检查OSD的日志文件。可以使用journalctl -u ceph-osd@{osd-id}命令查看OSD的日志,检查是否有错误信息。 检查OSD的磁盘状态:使用smartctl命令检查OSD所在磁盘的状态,包括磁盘的SMART信息、错误日志等。例如,使用smartctl -a /dev/{osd-disk}命令检查磁盘的状态。 修复故障的OSD:如果是磁盘问题,可以尝试重新连接、更换磁盘;如果是其他原因,可以尝试重启OSD进程或重新启动节点。 监控Ceph集群的性能指标 要监控Ceph集群的性能指标并进行性能调优和容量规划,可以采取以下步骤: 配置和启动监控工具:Ceph提供了多个监控工具,如Ceph-Dashboard、Grafana等。请根据具体情况选择合适的监控工具,并进行配置和启动。 监控性能指标:使用监控工具监控Ceph集群的性能指标,如吞吐量、IOPS、延迟等。可以查看集群总体的性能指标,也可以查看每个OSD的性能指标。 性能调优:根据监控得到的性能指标,可以进行性能调优。例如,根据瓶颈指标进行负载均衡,调整PG数量和大小,调整OSD的权重等。 容量规划:根据监控得到的容量使用情况,可以进行容量规划。例如,了解磁盘的使用情况,预测未来的容量需求,做好数据扩容的准备等。 应对Ceph集群中的网络延迟和带宽瓶颈问题 当Ceph集群中出现网络延迟和带宽瓶颈问题时,可以采取以下措施应对: 检查网络配置:确保Ceph集群的网络配置正确,包括网络拓扑、网卡参数、链路带宽等。可以使用ifconfig、ethtool等命令检查网络配置。 检查网络延迟:使用ping命令检查各个节点之间的网络延迟。可以检查响应时间和丢包情况,确定是否存在网络延迟问题。 增加带宽:如果带宽瓶颈是由于网络负载过重引起的,可以考虑增加带宽,包括增加网络带宽和优化网络路由等。 调整融合策略:Ceph支持多种融合策略来平衡网络负载,如利用链路聚合(Bonding)、利用虚拟局域网(VLAN)等。可以根据实际情况选择合适的融合策略。 优化MTU:适当调整网络设备的最大传输单元(MTU),可以减少网络传输的开销,提高网络性能。 解决网络故障:如果网络延迟和带宽瓶颈是由于网络设备故障引起的,可以尝试重新启动网络设备、更换网络设备或联系网（2023年12月28日的资料）

FAQ

问：OSD频繁出现down状态，如何快速恢复业务？

Ceph存储OSD故障频发怎么办？最新应对策略是什么？

答：首先使用ceph osd set noout防止数据重平衡，然后检查日志定位是网络还是磁盘问题。若是临时故障可尝试systemctl restart ceph-osd@{id}重启服务；若是硬件损坏则标记out并更换磁盘，最后解除noout标记让集群自动恢复。

问：Ceph集群在故障恢复期间如何避免IO性能下降？

答：可通过调整osd_recovery_sleep参数降低恢复速度，例如设置为0.5，同时限制osd_max_backfills和osd_recovery_max_active为1，采用低速恢复模式，优先保障前端业务的读写带宽。

问：如何预防因系统环境不兼容导致的OSD启动失败？

答：部署前需严格核对Ceph版本与Linux发行版、内核版本的兼容性矩阵，确保libceph内核模块正常加载，并检查XFS/EXT4文件系统是否支持d_type特性，避免因底层环境缺失导致服务反复崩溃。