ceph osd slow ops 检测

原创 已于 2023-02-28 16:55:03 修改 · 1.3k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#ceph

于 2023-02-28 16:42:44 首次发布
本文介绍了如何检测和处理Ceph存储系统中OSD（Object Storage Daemon）的慢操作问题，包括message layer、osd prepares、filestore问题、与本地磁盘相关的OSD事件，以及获取和修改OSD配置信息的方法。

目的

常用的方法检测 ceph slow 问题

参考

yceph -s
  cluster:
    id:     22908555-e596-4c2d-a1f6-34fcf4d3e935
    health: HEALTH_WARN
            Degraded data redundancy: 46384/12805029 objects degraded (0.362%), 145 pgs degraded, 122 pgs undersized
            309 slow ops, oldest one blocked for 252 sec, daemons [osd.0,osd.10,osd.101,osd.105,osd.106,osd.107,osd.110,osd.111,osd.112,osd.116]... have slow ops.

  services:
    mon: 3 daemons, quorum gd15-ceph-mon-dbbackup-003,gd15-ceph-mon-dbbackup-001,gd15-ceph-mon-dbbackup-002 (age 4d)
    mgr: gd15-ceph-mon-dbbackup-001(active, since 4d), standbys: gd15-ceph-mon-dbbackup-003
    mds: dba_fs:1 {0=gd15-ceph-mds-dbbackup-002=up:active} 2 up:standby
    osd: 152 osds: 152 up (since 28m), 152 in (since 51m); 122 remapped pgs

  data:
    pools:   3 pools, 4353 pgs
    objects: 4.27M objects, 16 TiB
    usage:   75 TiB used, 784 TiB / 860 TiB avail
    pgs:     46384/12805029 objects degraded (0.362%)
             1260/12805029 objects misplaced (0.010%)
             4205 active+clean
             119  active+recovery_wait+undersized+degraded+remapped
             24   active+recovery_wait+degraded
             2    active+recovering+undersized+remapped
             1    active+recovering+degraded
             1    active+recovery_wait
             1    active+recovering+undersized+degraded+remapped

  io:
    client:   7.5 GiB/s wr, 0 op/s rd, 2.04k op/s wr
    recovery: 10 MiB/s, 2 objects/s

检测 OSD slow 信息

ceph daemon /var/run/ceph/vip-ceph-osd.0.asok dump_ops_in_flight 
ceph daemon /var/run/ceph/vip-ceph-osd.0.asok dump_historic_ops

返回信息提示

message layer

信息解释
header_readWhen the messenger first started reading the message off the wire.
throttledWhen the messenger tried to acquire memory throttle space to read the message into memory.
all_readWhen the messenger finished reading the message off the wire.
dispatchedWhen the messenger gave the message to the OSD.
initiatedThis is identical to header_read. The existence of both is a historical oddity.

osd prepares

信息解释
queued_for_pgThe op has been put into the queue for processing by its PG.
reached_pgThe PG has started doing the op.
waiting for *The op is waiting for some other work to complete before it can proceed (e.g. a new OSDMap; for its object target to scrub; for the PG to finish peering; all as specified in the message).
startedThe op has been accepted as something the OSD should do and is now being performed.
waiting for subops fromThe op has been sent to replica OSDs.

filestore problem

信息解释
commit_queued_for_journal_writeThe op has been given to the FileStore.
write_thread_in_journal_bufferThe op is in the journal’s buffer and waiting to be persisted (as the next disk write).
journaled_completion_queuedThe op was journaled to disk and its callback queued for invocation.

osd 事件，与本地盘相关

信息解释
op_commitThe op has been committed by the primary OSD.
op_appliedThe op has been write()’en to the backing FS on the primary.
sub_op_applied: op_appliedFor a replica’s “subop”.
sub_op_committed: op_commitFor a replica’s sub-op (only for EC pools).
sub_op_commit_rec/sub_op_apply_rec from The primary marks this when it hears about the above, but for a particular replica (i.e. ).
commit_sentWe sent a reply back to the client (or primary OSD, for sub ops).

获取 osd 配置信息方法

ceph daemon /var/run/ceph/vip-ceph-osd.0.asok config  show

修改方法

ceph daemon /var/run/ceph/vip-ceph-osd.0.asok config  set name value
Ceph入门到精通- daemons [mon.node28,mon.node30] have slow ops. (SLOW_OPS)
隔壁老瓦的专栏
05-15 919
11 slow ops, oldest one blocked for 227608 sec, daemons [mon.node28,mon.node30] have slow ops. (SLOW_OPS)systemctl |grep mon.node28 ceph-f6ba7f6c-f073-11ed-947f-fcbcd1d038ed@mon.node28.service
Ceph入门到精通-CEPH故障以其处理方法
隔壁老瓦的专栏
09-13 2684
MDS服务器将元数据以segments(object)方式存放，当MDS中的segments数量超出mds_log_max_segments的设置值（默认为128）时，MDS服务开始启动Trimming，即将segments数据进行回写。OSDs之间会相互测试（ping）访问速度，若两个OSDs之间的连接延迟高于1s，则表示OSDs之间的延迟太高，不利于CEPH集群的数据存储和访问。当MDS使用的缓存过高，比设定的阈值高很多时，则有此警告信息。当有mds服务crash的时候，候选的mds则补上。
ceph HEALTH_WARN slow ops
mixboot
01-05 2394
ceph HEALTH_WARN slow opsHEALTH_WARN重启mon HEALTH_WARN health: HEALTH_WARN 2 slow ops, oldest one blocked for 116154 sec, mon.k093 has slow ops ceph health detail # ceph health detail HEALTH_WARN 2 slow ops, oldest one blocked for 116369 s
Ceph 4 slow ops, oldest one blocked for 638 sec, mon.cephnode01 has slow ops
热门推荐
Q先生
12-27 1万+
因为实验用的是虚拟机的关系，晚上一般会挂起。 第二天早上都能看到 4 slow ops, oldest one blocked for 638 sec, mon.cephnode01 has slow ops的报错。虽然不影响使用，但看着有点难受。 [root@ansible-01 ~]# ceph -s cluster: id: 38d10e08-7047-4341-bc8c...
ceph慢請求
Skyeee000的博客
07-26 1842
CEPH 集群”slow request“问题处理思路 什么是“slow request”请求 当一个请求长时间未能处理完成，ceph就会把该请求标记为慢请求（slow request）。 默认情况下，一个请求超过30秒未完成，就会被标记为slow request，并打印到日志文件（默认：/var/log/ceph/ceph.log）。请求超时时间由参数osd_op_complaint_time指定，并可以动态的修改。 另外，一个请求超过5分钟未完成，会导致所在的OSD Daemon程序异常退出（自杀），
ceph osd慢请求排查
yueyingshaqiu01的博客
04-02 1548
可以发现整个请求的耗时主要在header_read event，该耗时显示header_read到all_read期间耗时18.1s，可以分析得出osd在从messenger中读取(0-4M)的数据花了18s，该请求是从10.124.107.8于12:03:35的cephfs client发出，发往osd的，进一步可以去看看src dst在这个时间点的网络链路、CPU情况。
CEPH经常出现slow request的排查解决
weixin_30432179的博客
06-30 1649
现象： 通过ceph -w日志经常发现有request blocked的问题（如果虚拟机系统跑在ceph上时，就会发现严重的卡顿现象） 排查： 1、通过dstat未发现有明显的瓶颈 （dstat -tndr 2） 2、通过iostat也未发现有明显的瓶颈 (iostat -dx 2) 3、通过netstat也未发现存储网网卡的发送队列或者接收队列有明显的积压 (netstat ...
cephfs slow request 解决
Terry Tsang
07-09 898
cephfs slow request 分析方法
CEPH集群重启后ceph osd status和ceph -s命令查看发现节点服务器osd服务不成功的解决方案
LPFAM的博客
11-06 1584
CEPH集群重启后ceph osd status和ceph -s命令查看发现节点服务器osd服务不成功的解决方案 文章目录前言一：报错1.1：解决1.2：再次检查，发现问题已经解决 前言 实验环境部署ceph集群（结合openstack多节点），重启之后ceph集群的osd服务出现问题，解决如下 ceph+openstack多节点部署，有兴趣的可以查看我另一篇博客：https://blog.youkuaiyun.com/CN_TangZheng/article/details/104745364 一：报错 [roo
Ceph常用命令总结
洒满阳光的午后的博客
04-02 2133
【代码】Ceph常用命令总结。
ceph学习之路---ceph osd slow request问题解决
yysalad的专栏
05-15 4414
ceph集群中，osd日志如果有slow request，会出现osd down的情况，是可以从以下两个方面考虑解决问题： 1.检查防火墙是否关闭。 2.用iperf进行集群内网网络测试，一般集群内网做双网卡绑定，对应的交换机接口也会做聚合，如果是两个千兆网卡，绑定后的流量一般在1.8G左右，如果网络测试数据到不到绑定后的结果，或者网络带宽较低，会影响集群内部的数据交互，导致osd出现slow...
CEPH OSD_SLOW_PING_TIME_FRONT/BACK 警告处理
本尔2008的博客
03-11 3465
HEALTH_WARN Slow OSD heartbeats on back (longest 1093.720ms); Slow OSD heartbeats on front (longest 1088.357ms) [WRN] OSD_SLOW_PING_TIME_BACK: Slow OSD heartbeats on back (longest 1093.720ms) Slow OSD heartbeats on back from osd.15 [] to osd.192 [] 1093.72
【ceph】ceph集群 slow req 问题剖析：30 slow requests are blocked ＞ 32 sec. Implicated osds 186，满满都是干货
zerotoall的博客
11-24 962
【ceph】ceph集群 slow req 问题剖析：30 slow requests are blocked > 32 sec. Implicated osds 186，满满都是干货 1.硬件问题：dmest -T / smartctl -a 以及查看osd日志排查 2.网络问题：自己排查自己机器环境中的网络是否不稳定 一般使用iperf 或者 长ping 以及 http 响应时间 使用time 3.时间同步ntp也要检查 4.上面问题都排除外，大概率是shard分配不合理导致osd压力
解决Ceph 14.2.22 Nautilus版本监视器慢操作问题的实践指南
mixboot
05-08 546
解决Ceph 14.2.22 Nautilus版本监视器慢操作问题的实践指南
Ceph集群SSD故障检测
刘达的实验室
03-08 2910
Ceph集群SSD故障检测需求  目前在ceph的生产和测试环境中，我们通过几千块intel的DC S系列固态硬盘为ceph集群提供了后端的OSD对象存储服务的硬件底层，SSD因为其特性区别于传统的机械硬盘，在使用超过一定时间后其性能和健康状况会逐渐发生变化，故障率逐步升高。    硬盘的失效一般分为两种：可预测的（predictable）和不可预测的（unpredictable）。后者偶而会发生...
linux实例显示blocked,（11）ceph 告警：1 slow ops, oldest one blocked for
weixin_39630140的博客
05-15 2713
(1)ceph告警提示：1 slow ops, oldest one blocked for[[emailprotected] ~]# ceph -scluster:id: 58a12719-a5ed-4f95-b312-6efd6e34e558health: HEALTH_WARN1 slow ops, oldest one blocked for 1416 sec, mon.node...
cehp 维护（二）常见告警维护
tobias的博客
11-18 3520
零 修订记录 序号 修订时间 修订内容 1 r2021/11/18 新增 一 摘要 笨猪主要介绍ceph常见告警及维护方法或过程中遇到的问题 二 环境信息 2.1 ceph版本 [cephadmin@proceph01 ~]$ ceph -v ceph version 14.2.15 (afdd217ae5fb1ed3f60e16bd62357ca58cc650e5) nautilus (stable) [cephadmin@proceph01 ~]$ 2.2 操作系统版本 [ce
ceph 同步时间
mixboot
10-07 1049
health: HEALTH_WARN 32 slow ops, oldest one blocked for 4107 sec, daemons [mon.k093,mon.k094,mon.k095] have slow ops. # ceph health detail HEALTH_WARN 32 slow ops, oldest one blocked for 4422 sec, daemons [mon.k093,mon.k094,mon.k095] have slow
[Ceph] CacheTier的介绍与使用
分布式存储随笔
06-05 478
本文介绍如何部署ceph分层存储功能，并使用ceph分层存储功能。
ceph -s systemctl stop ceph-osd@210.service umount /var/lib/ceph/osd/ceph-210 ceph osd tree ceph osd out osd.210 ceph osd tree ceph osd crush remove osd.210 ceph osd tree ceph auth del osd.210 ceph osd tree ceph osd rm osd.210 ceph osd tree ceph -s 解释一下这些步骤的含义
最新发布
10-28
### 代码概述 您提供了一组完整的 Ceph 集群中 **删除 OSD 节点（osd.210）** 的操作命令序列，目标是从集群中安全下线并彻底移除一个故障或需更换的 OSD。 该请求基于明确的 Shell 命令列表和上下文文件 `cdn-lq-onestor11 osd210删盘操作.txt`，属于典型的运维脚本解析问题。虽然形式为文本，但本质是 **对一系列系统级命令的执行逻辑与含义进行深入分析**，因此判定为 **“代码型”** 问题。 --- ### 代码解析 我们将逐行讲解每条命令的作用、执行顺序的重要性以及背后的技术原理。 --- #### ✅ 步骤 1：查看集群整体状态 ```bash ceph -s ``` - **作用**：显示 Ceph 集群的当前健康状况。 - **输出关键信息**： - `HEALTH_OK` / `HEALTH_WARN` / `HEALTH_ERR` - PG 状态（如 `active+clean`, `degraded`） - OSD 数量、使用率等 📌 **目的**： - 确认集群当前是否稳定； - 记录初始状态，便于后续对比验证； - 若已有大量 `degraded` 或 `peering`，应暂缓操作。 --- #### ✅ 步骤 2：停止 OSD 服务进程 ```bash systemctl stop ceph-osd@210.service ``` - **作用**：终止编号为 210 的 OSD 守护进程。 - **效果**： - 该 OSD 不再响应读写请求； - 集群将其标记为 `down`； - 开始触发副本重建（前提是副本数足够）； ⚠️ 注意： - 必须先确保它已被设为 `out`（后面会执行），否则可能导致短暂中断； - 生产环境中建议先 `out` 再 `stop`，更安全。 --- #### ✅ 步骤 3：卸载数据目录 ```bash umount /var/lib/ceph/osd/ceph-210 ``` - **作用**：解除对 OSD 数据分区的挂载。 - **前提**： - 必须已执行 `systemctl stop ...`，否则提示“device busy”； - **路径说明**： - `/var/lib/ceph/osd/ceph-210` 是 `osd.210` 的工作目录； - 其中 `block` 文件是一个符号链接，指向底层设备（如 `/dev/sdb1`）； 📌 **目的**： - 准备物理移除硬盘前的安全清理； - 防止意外访问或 I/O 操作； - 为后续磁盘更换或重用做准备。 --- #### ✅ 步骤 4：查看 OSD 拓扑结构 ```bash ceph osd tree ``` - **作用**：显示当前所有 OSD 的层级拓扑图（包括 host、rack、host 上的 osd 列表及状态）。 - **输出示例**： ``` ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF -1 10.00000 pool default -3 10.00000 host cdn-lq-onestor11 210 7.28000 osd.210 down 1.00000 1.00000 ``` 📌 **目的**： - 确认 `osd.210` 当前状态（是否在线、所在主机）； - 为下一步操作提供可视化依据。 --- #### ✅ 步骤 5：将 OSD 标记为 out（不再参与存储） ```bash ceph osd out osd.210 ``` - **作用**：通知 CRUSH 算法，**不要再将新数据分配给这个 OSD**。 - **效果**： - 所有属于该 OSD 的 PG 将被重新映射到其他副本； - 数据开始迁移（recovery 或 backfill）； - 使用率逐渐归零； - **重要性**： - 避免在删除过程中丢失数据； - 是实现“平滑下线”的核心步骤。 > ⚠️ 提示：此命令可在 `stop` 之前执行更佳。 --- #### ✅ 步骤 6：再次查看拓扑（确认 out 已生效） ```bash ceph osd tree ``` - **目的**： - 验证 `osd.210` 是否已显示为 `out` 状态（权重变灰或标为 out）； - 观察其他 OSD 是否承担了新增负载； - 确保数据迁移已启动。 --- #### ✅ 步骤 7：从 CRUSH 映射中移除 ```bash ceph osd crush remove osd.210 ``` - **作用**：将 `osd.210` 从 CRUSH 层级结构中彻底删除。 - **CRUSH 是什么？** - Ceph 的数据分布算法，决定对象 → PG → OSD 的映射路径； - **意义**： - 移除后，该 OSD 永远不会再被选为数据存放位置； - 即使服务重启也不会恢复参与； - 是“永久剔除”的第一步。 📌 一旦执行，除非手动添加，否则无法自动回归。 --- #### ✅ 步骤 8：再次查看拓扑 ```bash ceph osd tree ``` - **目的**： - 验证 `osd.210` 是否已从树状结构中消失； - 确认 CRUSH 移除成功。 --- #### ✅ 步骤 9：删除认证密钥（防止非法接入） ```bash ceph auth del osd.210 ``` - **作用**：删除 `osd.210` 在集群中的身份认证信息（keyring）。 - **keyring 文件位置**： - 通常位于 `/var/lib/ceph/osd/ceph-210/keyring` - **为什么重要？** - 防止该 OSD 被恶意重启后重新加入集群； - 符合最小权限与安全审计要求； - 实现真正的“逻辑隔离”。 --- #### ✅ 步骤 10：再次查看拓扑 ```bash ceph osd tree ``` - 继续监控状态变化； - 确保前面的操作无异常反馈。 --- #### ✅ 步骤 11：从集群注册表中永久删除 ```bash ceph osd rm osd.210 ``` - **作用**：将 `osd.210` 从 Ceph 的元数据库中**永久注销**。 - **特点**： - 不可逆操作； - 必须确保已完成数据迁移； - 执行后 `ceph osd ls` 中不再出现 `210`； - **依赖条件**： - 已 `out`； - 已 `crush remove`； - 已 `auth del`； 📌 这是最关键的一步，完成“逻辑删除”。 --- #### ✅ 步骤 12：再次查看拓扑 ```bash ceph osd tree ``` - 最终确认 `osd.210` 是否完全消失； - 排查是否有残留条目或报错。 --- #### ✅ 步骤 13：最后检查集群状态 ```bash ceph -s ``` - **目的**： - 查看集群是否回到 `HEALTH_OK`； - 确认没有持续的 `degraded` 或 `stuck` PG； - 观察数据恢复进度（如有）； - **理想输出**： ```text health: HEALTH_OK ... pgs: 64 active+clean ``` ✅ 至此，整个删盘流程闭环完成。 --- ### 整体流程图解 ``` [开始] ↓ ceph -s ← 查看初始状态 ↓ systemctl stop ceph-osd@210 ← 停止服务 ↓ umount /var/lib/ceph/osd/ceph-210 ← 卸载数据目录 ↓ ceph osd tree → out osd.210 → tree ← 标记 out 并验证 ↓ ceph osd crush remove osd.210 ← 从 CRUSH 移除 ↓ ceph auth del osd.210 ← 删除认证 ↓ ceph osd rm osd.210 ← 永久删除注册 ↓ ceph osd tree × 多次 ← 持续验证状态 ↓ ceph -s ← 最终健康检查 [结束] ``` --- ### 为什么这个顺序很重要？ | 错误操作 | 风险 | |--------|------| | 先 `rm` 后 `out` | 数据可能未迁移完，导致丢失 | | 忘记 `auth del` | 安全隐患，OSD 可能被重新启用 | | 不看 `ceph -s` | 无法判断是否真正恢复 | 📌 **推荐顺序总结**： 1. `ceph -s` 2. `ceph osd out osd.X` 3. `ceph osd tree`（验证） 4. `systemctl stop ceph-osd@X` 5. `umount /var/lib/ceph/osd/ceph-X` 6. `ceph osd crush remove osd.X` 7. `ceph auth del osd.X` 8. `ceph osd rm osd.X` 9. `ceph osd tree` 和 `ceph -s` 多次验证 --- ### 知识点 - **OSD安全下线流程闭环机制**：通过out→crush remove→auth del→rm四步实现逻辑与安全双重清除，保障集群稳定性。 - **CRUSH算法动态剔除能力**：crush remove指令使OSD立即退出数据分布计算，阻止未来分配，是实现弹性伸缩的关键。 - **ceph -s与ceph osd tree实时监控作用**：前者反映全局健康，后者展示节点拓扑变迁，共同构成运维决策依据。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Terry_Tsang

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值