ceph 故障分析(backfill_toofull)

在执行了 ceph 扩容之前, 发现长时间内都具有下面的状态存在
参考下面信息

# ceph -s
    cluster dc4f91c1-8792-4948-b68f-2fcea75f53b9
     health HEALTH_WARN 13 pgs backfill_toofull; 1 pgs degraded; 1 pgs stuck degraded; 13 pgs stuck unclean; 9 requests are blocked > 32 sec; recovery 190/54152986 objects degraded (0.000%); 47030/54152986 objects misplaced (0.087%); 2 near full osd(s); clock skew detected on mon.hh-yun-ceph-cinder025-128075
     monmap e3: 5 mons at {hh-yun-ceph-cinder015-128055=240.30.128.55:6789/0,hh-yun-ceph-cinder017-128057=240.30.128.57:6789/0,hh-yun-ceph-cinder024-128074=240.30.128.74:6789/0,hh-yun-ceph-cinder025-128075=240.30.128.75:6789/0,hh-yun-ceph-cinder026-128076=240.30.128.76:6789/0}, election epoch 168, quorum 0,1,2,3,4 hh-yun-ceph-cinder015-128055,hh-yun-ceph-cinder017-128057,hh-yun-ceph-cinder024-128074,hh-yun-ceph-cinder025-128075,hh-yun-ceph-cinder026-128076
     osdmap e23216: 100 osds: 100 up, 100 in
      pgmap v11159189: 20544 pgs, 2 pools, 70024 GB data, 17620 kobjects
            205 TB used, 158 TB / 363 TB avail
            190/54152986 objects degraded (0.000%); 47030/54152986 objects misplaced (0.087%)
               20527 active+clean
                   1 active+degraded+remapped+backfill_toofull
                   4 active+clean+scrubbing+deep
                  12 active+remapped+backfill_toofull
  client io 7609 kB/s rd, 46866 kB/s wr, 1909 op/s

参考重点:

12 active+remapped+backfill_toofull
1 active+degraded+remapped+backfill_toofull

获得 pg 详细信息

# ceph pg dump 2> /dev/null | grep -E 'pg_stat|toofull' | awk '{printf "%-8s %-15s %-15s %-15s %-55s\n", $1, $7, $15, $17, $10}'
pg_stat  bytes           up_primary      acting_primary  state
1.19ae   4427174912      [50,24,31]      [21,33,69]      active+remapped+backfill_toofull
1.f51    2313255936      [51,8,24]       [8,31,58]       active+remapped+backfill_toofull
1.86f    2199311872      [57,24,18]      [57,22,65]      active+degraded+remapped+backfill_toofull
1.531    2257795584      [12,59,24]      [12,59,31]      active+remapped+backfill_toofull
1.186    2359985152      [51,8,24]       [2,27,57]       active+remapped+backfill_toofull
1.4f35   2429229056      [52,24,38]      [12,26,57]      active+remapped+backfill_toofull
1.44cb   2247723008      [51,24,18]      [15,26,60]      active+remapped+backfill_toofull
1.405e   2286564864      [50,24,14]      [16,27,40]      active+remapped+backfill_toofull
1.3bc2   4308700672      [55,12,24]      [55,14,40]      active+remapped+backfill_toofull
1.3b35   4711967232      [43,52,24]      [43,19,26]      active+remapped+backfill_toofull
1.3845   4573419008      [12,59,24]      [12,29,43]      active+remapped+backfill_toofull
1.35f3   4424525312      [45,58,24]      [45,23,59]      active+remapped+backfill_toofull
1.291f   4661793280      [14,50,24]      [14,21,48]      active+remapped+backfill_toofull

参考上面资料

1. 当前有约莫 12 个 PG,  PG 容量约为 2GB ~ 4.5GB 空间,
2. 参考 up_primary, 每个 pg 都需要占用 osd.24 作为数据存储空间

参考当前 OSD 容量

total  used  free  ptc   target
3.7T   3.2T  539G  86%   /var/lib/ceph/osd/ceph-24 

当前所有故障 PG 需要执行磁盘迁移
磁盘迁移时候, 都需要把数据存放至 OSD.24 中
约莫需要存 40GB 数据到上述 OSD 存储中
当前 OSD.24 磁盘容量空间为 86%
由于 osd near full 设定为 .85
因此, ceph 集群会认为该 osd 空间容量不足, 导致长时间都属于该状态中

时间: 2024-07-31 15:41:50

ceph 故障分析(backfill_toofull)的相关文章

ceph - 索引

架构与部署 openstack 与 ceph (架构) openstack 与 ceph (monitor初始化) openstack 与 ceph (osd 部署) openstack 与 ceph ( pool 管理 ) openstack 管理二十二 - cinder 连接多个存储 backend openstack 管理二十三 - nova compute 连接 ceph 集群 ceph - crush map 与 pool ceph - 更改 ceph journal 位置 故障与测试

ceph - pg 常见状态

说明 pg ( placement group ) 是数据存储的重要单位 在使用 ceph 的时候, pg 会经常发生状态的变化, 参考下面例子 当创建池的时候, 将会创建相应的 pg, 那么可以看到 pg creating 状态 当部分 pg 创建成功后, 将会发现 pg 会进入 peering 状态 当所有 pg peering 完成后, 将可见到状态变成 active+clean 参考下面常见的 pg 状态 creating (创建中) PG 正在被创建, 通常当存储池正在卑创建或增加一个

ceph GLOSSARY

ceph文档里术语较多, 为了方便理解, 最好先了解一下ceph的术语. 以下摘自ceph doc, 少了PG. PG placement group      PG, 存储 object 的逻辑组. PG存储在OSD中. OSD包含journal和data. 写完journal后返回ack确认数据安全性.      一般journal使用SSD来存储, 需要高的响应速度(类型postgresql xlog)      Ceph stores a client's data as objects

ceph recommendation - os

内核版本 :  v3.16.3 or later (rbd deadlock regression in v3.16.[0-2]) v3.14.* v3.10.* 注意, 如果要使用firefly 的 crush tunables功能, 建议使用v3.16.3内核. firefly (CRUSH_TUNABLES3) tunables are supported starting with v3.15. See CRUSH Tunables for more details. 如果要使用 btr

ceph performance tune , mount the osd mon data directory to diff block dev

在centos或rhel中, ceph服务可以通过ceph sysv脚本来管理, 例如用来管理mds, osd, mon节点. 如下 : # less /etc/init.d/ceph usage_exit() { echo "usage: $0 [options] {start|stop|restart|condrestart} [mon|osd|mds]..." printf "\t-c ceph.conf\n" printf "\t--cluster

工作中遇到的oracle故障分析和处理一例

oracle 案例类别:VAS网络 系统类型:CMODE系统版本:硬件:SUN  软件:所有版本案例标题:CMODE放号中的数据库出现LOCK的处理方法 故障现象:启动sam_cmode进程不能正常处理工单.故障描述:启动以sam_cmode –d方式启动发现sam_cmode始终在处理一个用户.connected4c 4f 47 49 4e 3a 55 53 45 52 4e 41 4d 45 3d 22 75 74 62 6a 22 2c 50 41 53 53 57 4f 52 44 3d

鼠标常见故障分析与维修技巧

鼠标的故障分析与维修比较简单,大部分故障为接口或按键接触不良.断线.机械定位系统脏污.少数故障为鼠标内部元器件或电路虚焊,这主要存在于某些劣质产品中,其中尤以发光二极管.IC电路损坏居多. 一.找不到鼠标 1.鼠标彻底损坏,需要更换新鼠标. 2.鼠标与主机连接串口或PS/2口接触不良,仔细接好线后,重新启动即可. 3.主板上的串口或PS/2口损坏,这种情况很少见,假如是这种情况,只好去更换一个主板或使用多功能卡上的串口. 4.鼠标线路接触不良,这种情况是最常见的.接触不良的点多在鼠标内部的电线与

Linux中的系统故障分析与排查

在处理Linux系统出现的各种故障时,故障的症状是最先发现的,而导致这以故障的原因才是最终排除故障的关键.熟悉Linux系统的日志管理,了解常见故障的分析与解决办法,将有助于管理员快速定位故障点."对症下药"及时解决各种系统问题. 1.日志分析及管理 日志文件是用于记录Linux系统中各种运行消息的文件,相当于Linux主机的"日记".不同的日志文件记载了不同类型的信息,如:Linux内核消息,用户登录记录,程序错误等.日志文件对于诊断和解决系统中的问题很有帮助,因

如何将 Ceph 存储集群集成到 OpenStack 云中

了解 Ceph,这是一个能够增强您的 OpenStack 环境的开源分布式存储系统 Ceph 是一个符合 POSIX (Portable Operating System for UNIX).开源的分布式存储系统,依据 GNU 次通用公共许可而运行.该项目最初由 Sage Weill 于 2007 年开发,该项目的理念是提出一个没有任何单点故障的集群,确保能够跨集群节点进行永久数据复制. 与在任何经典的分布式文件系统中一样,放入集群中的文件是条带化的,依据一种称为 Ceph Controlled