重启ceph的错误health HEALTH_ERR [56 pgs are stuck inactive for more than 300 seconds]

最新推荐文章于 2023-10-24 11:42:17 发布
原创 最新推荐文章于 2023-10-24 11:42:17 发布 · 3.7k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

文章详细介绍了在Ceph集群管理中遇到的问题：在配置主管理节点时，因未在所有节点添加UDEV规则而导致vdb1和vdb2设备重启后权限归属错误。通过在每个节点的/uve/rules.d目录下创建并编辑90-cephdisk.rules文件，添加了相应的UDEV规则，从而解决了设备权限归属问题。操作步骤包括编辑规则文件、重启主机以应用更改。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

重启ceph的时候，在配置主管理节点查看ceph的状态的时候报错。


报错原因是忘记在node2，node3节点加UDEV规则，使得vdb1和vdb2重启后，属主属组仍然是ceph，在配置的ceph的三个节点加入以下的规则，在重启三台主机。

[root@node1~]# vim /etc/udev/rules.d/90-cephdisk.rules

ACTION=="add",KERNEL=="vdb[12]", OWNER="ceph", GROUP="ceph"

[root@node1~]# vim /etc/udev/rules.d/90-cephdisk.rules

ACTION=="add",KERNEL=="vdb[12]", OWNER="ceph", GROUP="ceph"

[root@node2~]# vim /etc/udev/rules.d/90-cephdisk.rules

ACTION=="add",KERNEL=="vdb[12]", OWNER="ceph", GROUP="ceph"

[root@node3~]# vim /etc/udev/rules.d/90-cephdisk.rules

ACTION=="add",KERNEL=="vdb[12]", OWNER="ceph", GROUP="ceph"



zhy-dream
关注
重启ceph集群顺序
weixin_40548182的博客
03-23 764
1、告知ceph集群不要将OSD标记为out。命令 ceph osd unset noout。命令 ceph osd set noout。网关，例如NFS Ganesha或对象网关。网关，例如NFS Ganesha或对象网关。1、以与停止过程相关的顺序启动节点。2、按如下顺序停止守护进程和节点。2、删除noout标志。
解决ceph部署完成之后出现 “ 128 pgs are stuck inactive for more than 300 seconds”的问题
ZZZZZZKAI的博客
08-28 8281
在部署ceph的时候，由于是在自己的虚拟机上测试部署，完成之后出现如下截图故障：        后来一直分析这个原因，网上也有一些同样的问题，但是没有比较清晰的答案，后来分析发现这个过程中pg一直处于creating的状态。这个问题其实是出现在前面一步，在执行ceph-deploy new 这一步之后，有一个修改ceph.conf的步骤，这个过程中加了一行 ：os
【ceph学习笔记】ceph -s 出现health HEALTH_ERR，pg remapped
运维少年
09-10 3885
背景 查看ceph集群状态的时候出现了ERR的错误，报错如下 [root@node1 ceph]# ceph -s cluster 8eaa3f15-0946-4500-b018-6d31d1cc69f6 health HEALTH_ERR clock skew detected on mon.node2, mon.node3 54...
Ceph，health HEALTH_ERR错误
肓己优快云
06-21 7420
本来头一天晚上还是正常的ceph存储集群，经历了一个不明真相的夜晚之后启动机器发现集群的健康检查状态已经是HEALTH_ERR了： [root@node1 ~]# ceph -s cluster 056c396d-639c-4312-9ea0-794c92e57329 health HEALTH_ERR 38 pgs are stuck inactive...
ceph：HEALTH_ERR 41 pgs are stuck inactive for more than 300 seconds；
Entity_G的博客
12-19 990
今天学习ceph部署时，发现集群状态异常猜测：测试添加osd和删除osd时，没有清理干净或者没有使用正确的方法清理。
ceph HEALTH_ERR 1 scrub errors
mixboot
01-07 1293
ceph HEALTH_ERR 1 scrub errorsceph health detailceph pg repairpg repair 需要等待几分钟 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
ceph集群报错：HEALTH_ERR 1 pgs inconsistent; 1 scrub errors
无锋剑
07-24 2965
报错信息如下：[root@ceph-6-11 ~]# ceph health detailHEALTH_ERR 1 pgs inconsistent; 1 scrub errors; pg 2.37c is active+clean+inconsistent, acting [75,6,35]1 scrub errors报错信息总结：问题PG：2.37cOSD编号：75,6,35执行常规修复：ce...
ceph安装记录总结
雨点的专栏
01-15 469
1、环境准备 ·准备三台虚机，每个虚机配合三块数据盘，2块网卡，一个网卡设置外网，一个网卡设置成内网 ·配置文件设置（根据实际情况配置每一个节点） -编辑 letc/sysconfig/network-scripts/ifcfg-ethO 文件（外网），添加 ONBOOT=yes BOOTPROTO=dhcp -编辑 letc/sysconfig/network scripts/ifcfg-eth 文件（内网），添加: ONBOOT=yes...
ceph_health_status > 1
02-26
ceph pg dump_stuck inactive ``` --- ### **监控与预防** - **设置告警**：通过 Prometheus + Grafana 监控 Ceph 指标（如 `ceph_health_status`）。 - **定期维护**：更新 Ceph 版本、清理冗余数据、检查硬件...
ceph PG 状态恢复不了的问题 （来自ceph-devel邮件）
为梦想而追逐，厚积而薄发
05-24 3277
The thing where you can't query a PG is because the OSD is throttling incoming work and the throttle is exhausted (the PG can't do work so it isn't making progress). A workaround for jewel is to r
ceph配置错误 health HEALTH_ERR clock skew detected on mon.node2, mon.node3
朱海燕的博客日记
07-14 7485
错误提示：clock skew detected on mon.node2, mon.node3错误翻译：在mon.node2，mon.node3上检测到时钟偏差错误的原因：控制节点node2，node3没有和相应都时间同步协议服务器同步，在这两台节点上开启相同的服务，如果没有效果则需要等一点时间或者重启第二次后查看。[root@node2 ~]#  systemctl restart chron...
解决方法512 pgs are stuck inactive for more than 300 seconds
二哈欢乐多的博客
02-26 4917
当前ceph集群试了很多方式都没能解决，加pg啦 等等，发现问题依旧   慢慢排查发现。crush_ruleset  有一个不一致        ceph osd pool set   <pool> crush_ruleset 1  等待一段时间发现问题解决 ceph  -s  集群ok   ...
CEPH HEALTH错误（二）：HEALTH_WARN mds cluster is degraded
zhu19774279的专栏
06-03 5217
今天重启虚拟机后，直接运行ceph health，但是却提示HEALTH_WARN mds cluster is degraded，如下图所示： 解决办法有2步，第一步启动所有节点： service ceph -a start 第二部，激活osd节点（我这里有2个osd节点）： ceph-deploy osd activate HA-163:/var/local/osd0 mysq
Ceph 12 报错：health: HEALTH_ERR 1 scrub errors Possible data damage: 1 pg inconsistent
Mr_Apple 的空间
10-18 2044
报错如下： [root@EQUHST00003805 cluster_info]# ceph -s cluster: id: be0e22db-d85d-49db-a20d-dede18b7888e health: HEALTH_ERR 1 scrub errors Possible data damage: 1 pg i...
Ceph重启命令
weixin_42340926的博客
01-11 3327
所有ceph的服务开启、关闭等 systemctl start ceph.target 按照服务分类开启、关闭等 systemctl start ceph-mon.target systemctl start ceph-mgr.target systemctl start ceph.osd.target 更加细粒度的服务开启、关闭 systemctl start ceph-osd@{osd Id} ...
存储重启后，ceph挂载信息没了，手动定位osd序号并挂载到对应磁盘操作流程、ceph查看不到osd信息处理方法
崔崇鑫的博客，你linux/云运维工作中的百科全书。
07-27 1294
因为挂载信息没有写到fstab里面，所以不会自动up，并且没有挂载信息，并且也看不到osd信息了，需要手动一一挂载后才能正常up和看到osd信息。我们的一个存储节点莫名其妙的重启了，不知道咋回事。但这样的问题就是，所有osd都down了。
Ceph入门到精通-Node异常重启，podman osd容器无法启动 ExitCode msg: “crun: mkdir /sys/fs/selinux: operation not permit
隔壁老瓦的专栏
06-02 1214
修改/etc/sysconfig/selinux 文件
ceph命令系列（二）：Ceph集群启动/停止/重启命令
热门推荐
Yannick Jiang 的专栏
06-25 2万+
Ceph-deploy命令安装好集群后，可以操作其维护命令。我安装的版本是luminous(12.2.11)，ceph脚本对应/usr/bin/ceph文件，这个版本已经没有/etc/init.d/ceph [option] [start/stop/restart]了。centos使用systemctl，ubuntu使用service命令来操作ceph服务。 $ ceph --version...
【ceph】ceph集群的节点机器重启，导致磁盘的lvm消失，如何恢复呢～～满满的都是干货
zerotoall的博客
10-24 635
【ceph】ceph集群的节点机器重启，导致磁盘的lvm消失，如何恢复呢～～满满的都是干货
ceph_osd_perf_apply_latency_seconds * 1000 > 500
最新发布
02-26
<think>好的，我现在需要处理用户的问题：“请使用中文回答我或者给我介绍一下: ceph_osd_perf_apply_latency_seconds * 1000 > 500”。首先，用户之前询问过关于Ceph RBD读取延迟的PromQL表达式，现在这个问题也是关于Ceph监控指标的，但这次是OSD的应用延迟。我需要先理解这个表达式的含义，以及用户可能的意图。 首先，用户给出的表达式是“ceph_osd_perf_apply_latency_seconds * 1000 > 500”。看起来这是一个PromQL查询，用于监控Ceph OSD的应用延迟是否超过500毫秒。用户可能希望了解这个表达式的用途、结构以及背后的监控逻辑。 接下来，我需要拆解这个表达式。ceph_osd_perf_apply_latency_seconds应该是Ceph OSD处理写入请求的延迟时间，单位是秒。乘以1000是为了将单位转换为毫秒，然后检查是否大于500。所以整个表达式的作用是筛选出应用延迟超过500毫秒的OSD实例。 用户可能在使用Prometheus监控Ceph集群，特别是OSD的性能。他们可能遇到了延迟问题，或者想设置警报，当延迟超过一定阈值时触发。因此，用户需要确认这个表达式的正确性，以及背后的指标含义，确保监控的有效性。 我需要考虑用户可能的背景。他们可能是运维人员或开发人员，负责维护Ceph集群，需要监控OSD的性能指标。之前的提问关于RBD读取延迟，现在转向OSD的应用延迟，说明他们在全面监控Ceph的不同组件，关注性能问题。 接下来，我需要验证这个PromQL的正确性。首先，确认指标名称是否正确。Ceph的监控指标通常通过ceph-exporter或类似的工具导出，不同的版本可能有不同的指标命名习惯。例如，是否存在ceph_osd_perf_apply_latency_seconds这个指标，或者是否有类似名称的指标，比如ceph_osd_apply_latency_seconds。如果用户写错了指标名称，可能会导致查询结果不准确。 其次，应用延迟的具体含义是什么？Apply latency通常指OSD处理写操作的时间，包括将数据写入日志和最终落盘的时间。用户需要了解这个指标反映的是OSD处理请求的效率，高延迟可能意味着磁盘性能问题、网络延迟或OSD过载。 然后，检查单位转换是否正确。原指标单位是秒，乘以1000转换为毫秒是合理的，但需要确认指标的实际单位是否确实是秒，避免误解。比如，有些指标可能以毫秒为单位，这时候转换就会出错。 此外，比较运算符“> 500”是否正确？用户可能想筛选延迟超过500毫秒的情况，但需要结合实际情况判断这个阈值是否合理。500毫秒对于存储系统来说可能已经很高，但具体取决于集群的配置和性能要求。用户可能需要根据历史数据调整阈值。 另外，PromQL的语法是否正确？表达式是否合法？比如，乘法运算符的使用是否正确，是否需要使用函数如rate或irate来处理计数器指标。这里可能存在误区，因为通常延迟指标可能是直方图或Summary类型，而不是简单的Gauge。如果ceph_osd_perf_apply_latency_seconds是一个直方图，那么可能需要使用rate函数来计算一段时间内的平均延迟，而不是直接使用该指标的值。 例如，正确的处理方式可能是：rate(ceph_osd_perf_apply_latency_seconds_sum[5m]) / rate(ceph_osd_perf_apply_latency_seconds_count[5m]) * 1000 > 500，这样计算的是平均延迟。如果用户直接使用该指标而没有考虑rate或irate，可能会得到错误的结果，因为累积值会不断增长，无法直接反映当前延迟。 因此，用户当前的表达式可能存在问题，需要进一步确认指标类型和正确的查询方式。如果用户直接使用了一个Gauge类型的指标，那么表达式是有效的，但如果是计数器类型，就需要使用rate或irate来处理。 另外，用户可能没有考虑到多个标签的情况，比如不同的OSD、集群、主机等。表达式是否需要按某些标签进行分组或聚合？例如，按OSD实例分组，以便查看每个OSD的延迟情况，而不是整体的情况。如果用户希望每个OSD单独判断，可能需要使用by (instance)或者其他相关标签。 此外，用户可能希望设置警报规则，当有任意OSD的延迟超过阈值时触发警报。这时候，PromQL需要正确返回所有超过阈值的实例，以便警报能够准确触发。 总结下来，我需要向用户解释以下几点： 1. 表达式的目的：监控Ceph OSD的应用延迟是否超过500毫秒。 2. 指标的含义：ceph_osd_perf_apply_latency_seconds的定义和单位。 3. 可能的语法问题：是否正确处理了指标类型（Gauge还是Counter），是否需要使用rate/irate函数。 4. 单位转换是否正确，阈值是否合理。 5. 是否需要聚合或分组，以正确显示各个OSD的情况。 6. 使用该表达式时的注意事项，比如指标是否存在、时间窗口的选择等。 同时，用户可能存在的深层需求是有效监控OSD性能，及时发现问题，并设置合理的警报。因此，除了解释当前表达式，还需要提供优化建议，比如正确的PromQL写法、阈值调整、结合其他指标分析等，帮助用户更好地实现监控目标。 最后，确保回答清晰易懂，结构合理，涵盖用户可能关心的问题点，并指出潜在的问题和解决方案，避免用户在使用过程中遇到问题。</think>以下是对 `ceph_osd_perf_apply_latency_seconds * 1000 > 500` 的详细解释和分析： --- ### **表达式的目的** 该 PromQL 表达式用于 **监控 Ceph OSD（Object Storage Daemon）的写入应用延迟**，并筛选出延迟超过 **500 毫秒** 的 OSD 实例。核心目标是识别性能异常的 OSD，帮助运维人员快速定位存储集群中的高延迟问题。 --- ### **指标拆解** #### 1. **指标含义** - **`ceph_osd_perf_apply_latency_seconds`** 表示 Ceph OSD 处理写入请求的 *应用延迟*（Apply Latency），即从 OSD 接收到写入请求到数据成功写入磁盘的总时间。 - 单位：**秒**（通过 `* 1000` 转换为毫秒）。 - 标签：通常包含 `ceph_cluster`（集群名称）、`osd`（OSD 编号）、`instance`（主机实例）等维度。 #### 2. **表达式逻辑** - **`ceph_osd_perf_apply_latency_seconds * 1000`** 将延迟单位从秒转换为毫秒，便于更直观的监控（例如，`0.5秒` → `500毫秒`）。 - **`> 500`** 筛选出应用延迟超过 **500 毫秒** 的 OSD 实例。 --- ### **适用场景** 1. **性能告警** 当 OSD 的写入延迟持续高于阈值（500ms）时，触发告警，提示可能存在磁盘性能问题或网络瓶颈。 2. **根因分析** 结合其他指标（如 CPU、磁盘 IO、网络流量），定位高延迟的具体原因（例如慢盘、硬件故障、负载过高等）。 3. **横向对比** 比较不同 OSD、主机或集群的延迟表现，识别性能瓶颈的分布。 --- ### **潜在问题与改进建议** #### 1. **指标类型需确认** - **假设验证**： 需要确认 `ceph_osd_perf_apply_latency_seconds` 是否为 **直方图（Histogram）** 或 **Summary 类型** 的指标（通常存储延迟类指标是这类类型）。 - **问题**： 如果该指标是 Counter 类型（累计值），直接查询其瞬时值无意义，需改用 `rate()` 或 `irate()` 计算单位时间增量。 - **改进建议**： 如果是直方图/Summary 类型，更规范的写法是： ```promql (sum(rate(ceph_osd_perf_apply_latency_seconds_sum[2m])) by (osd, instance)) / (sum(rate(ceph_osd_perf_apply_latency_seconds_count[2m])) by (osd, instance)) * 1000 > 500 ``` 这会计算过去 2 分钟内 OSD 的平均应用延迟。 #### 2. **阈值合理性** - **500 毫秒的适用性**： Ceph 的 OSD 延迟通常要求更低（例如，SSD 环境下建议小于 50ms）。500ms 可能过高，需根据实际硬件性能调整阈值。 - **建议**： 结合历史数据（P99/P95 分位数）设置动态阈值，或分场景定义： ```promql # 普通 HDD 环境 ceph_osd_perf_apply_latency_seconds * 1000 > 200 # 高性能 SSD 环境 ceph_osd_perf_apply_latency_seconds * 1000 > 50 ``` #### 3. **单位转换优化** - **显式标注单位**： 建议在查询结果中注明单位，避免歧义： ```promql (ceph_osd_perf_apply_latency_seconds * 1000) > 500 # 结果展示为 "apply_latency_ms" ``` #### 4. **关联分析** - **结合其他指标**： 高延迟可能由多种因素引起，需综合以下指标分析： ```promql # 磁盘 IO 延迟 node_disk_io_time_seconds{device="osd_disk"} # 网络延迟 rate(ceph_osd_ping_latency_seconds[5m]) # CPU 使用率 rate(node_cpu_seconds_total{mode="idle"}[5m]) ``` --- ### **示例输出** 假设查询结果返回： ``` {ceph_cluster="prod-cluster", osd="osd.1", instance="10.0.0.1:9283"} 623 {ceph_cluster="prod-cluster", osd="osd.3", instance="10.0.0.2:9283"} 810 ``` 表示 OSD.1 和 OSD.3 的应用延迟分别为 623ms 和 810ms，需要进一步排查这些节点的磁盘、网络或负载情况。 --- ### **总结** - **核心作用**：监控 OSD 写入延迟，识别性能瓶颈。 - **关键改进点**： - 确认指标类型，必要时修正为基于 `rate()` 的计算。 - 根据实际环境调整阈值。 - 结合多维指标进行根因分析。 如果有更多上下文（如 Ceph 版本、监控工具类型），可进一步优化表达式！
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值