HarmonyOS开发者限时福利来啦!最高10w+现金激励等你拿~ 了解详情
写点什么

分布式存储系统 Ceph 之 PG 状态详解

  • 2018-11-15
  • 本文字数:10523 字

    阅读完需:约 35 分钟

分布式存储系统Ceph之PG状态详解

1. PG 介绍

继上次分享的《Ceph介绍及原理架构分享》,这次主要来分享 Ceph 中的 PG 各种状态详解,PG 是最复杂和难于理解的概念之一,PG 的复杂如下:


  • 在架构层次上,PG 位于 RADOS 层的中间。

  • a. 往上负责接收和处理来自客户端的请求。

  • b. 往下负责将这些数据请求翻译为能够被本地对象存储所能理解的事务。

  • 是组成存储池的基本单位,存储池中的很多特性,都是直接依托于 PG 实现的。

  • 面向容灾域的备份策略使得一般而言的 PG 需要执行跨节点的分布式写,因此数据在不同节点之间的同步、恢复时的数据修复也都是依赖 PG 完成。

2. PG 状态表

正常的 PG 状态是 100%的 active + clean, 这表示所有的 PG 是可访问的,所有副本都对全部 PG 都可用。


如果 Ceph 也报告 PG 的其他的警告或者错误状态。PG 状态表:


状态描述
ActivatingPeering已经完成,PG正在等待所有PG实例同步并固化Peering的结果(Info、Log等)
Active活跃态。PG可以正常处理来自客户端的读写请求
Backfilling正在后台填充态。 backfill是recovery的一种特殊场景,指peering完成后,如果基于当前权威日志无法对Up Set当中的某些PG实例实施增量同步(例如承载这些PG实例的OSD离线太久,或者是新的OSD加入集群导致的PG实例整体迁移) 则通过完全拷贝当前Primary所有对象的方式进行全量同步
Backfill-toofull某个需要被Backfill的PG实例,其所在的OSD可用空间不足,Backfill流程当前被挂起
Backfill-wait等待Backfill 资源预留
Clean干净态。PG当前不存在待修复的对象, Acting Set和Up Set内容一致,并且大小等于存储池的副本数
CreatingPG正在被创建
DeepPG正在或者即将进行对象一致性扫描清洗
Degraded降级状态。Peering完成后,PG检测到任意一个PG实例存在不一致(需要被同步/修复)的对象,或者当前ActingSet 小于存储池副本数
DownPeering过程中,PG检测到某个不能被跳过的Interval中(例如该Interval期间,PG完成了Peering,并且成功切换至Active状态,从而有可能正常处理了来自客户端的读写请求),当前剩余在线的OSD不足以完成数据修复
IncompletePeering过程中, 由于 a. 无非选出权威日志 b. 通过choose_acting选出的Acting Set后续不足以完成数据修复,导致Peering无非正常完成
Inconsistent不一致态。集群清理和深度清理后检测到PG中的对象在副本存在不一致,例如对象的文件大小不一致或Recovery结束后一个对象的副本丢失
PeeredPeering已经完成,但是PG当前ActingSet规模小于存储池规定的最小副本数(min_size)
Peering正在同步态。PG正在执行同步处理
Recovering正在恢复态。集群正在执行迁移或同步对象和他们的副本
Recovering-wait等待Recovery资源预留
Remapped重新映射态。PG活动集任何的一个改变,数据发生从老活动集到新活动集的迁移。在迁移期间还是用老的活动集中的主OSD处理客户端请求,一旦迁移完成新活动集中的主OSD开始处理
RepairPG在执行Scrub过程中,如果发现存在不一致的对象,并且能够修复,则自动进行修复状态
ScrubbingPG正在或者即将进行对象一致性扫描
Unactive非活跃态。PG不能处理读写请求
Unclean非干净态。PG不能从上一个失败中恢复
Stale未刷新态。PG状态没有被任何OSD更新,这说明所有存储这个PG的OSD可能挂掉, 或者Mon没有检测到Primary统计信息(网络抖动)
UndersizedPG当前Acting Set小于存储池副本数

3. 状态详解及故障模拟复现

3.1 Degraded

3.1.1 说明


  • 降级:由上文可以得知,每个 PG 有三个副本,分别保存在不同的 OSD 中,在非故障情况下,这个 PG 是 active+clean 状态,那么,如果 PG 的 副本 osd.4 挂掉了,这个 PG 是降级状态。


3.1.2 故障模拟


a. 停止 osd.1


$ systemctl stop ceph-osd@1
复制代码


b. 查看 PG 状态


$ bin/ceph pg stat20 pgs: 20 active+undersized+degraded; 14512 kB data, 302 GB used, 6388 GB / 6691 GB avail; 12/36 objects degraded (33.333%)
复制代码


c. 查看集群监控状态


$ bin/ceph health detailHEALTH_WARN 1 osds down; Degraded data redundancy: 12/36 objects degraded (33.333%), 20 pgs unclean, 20 pgs degraded; application not enabled on 1 pool(s)OSD_DOWN 1 osds down    osd.1 (root=default,host=ceph-xx-cc00) is downPG_DEGRADED Degraded data redundancy: 12/36 objects degraded (33.333%), 20 pgs unclean, 20 pgs degraded    pg 1.0 is active+undersized+degraded, acting [0,2]    pg 1.1 is active+undersized+degraded, acting [2,0]
复制代码


d. 客户端 IO 操作


#写入对象$ bin/rados -p test_pool put myobject ceph.conf
#读取对象到文件$ bin/rados -p test_pool get myobject.old
#查看文件$ ll ceph.conf*-rw-r--r-- 1 root root 6211 Jun 25 14:01 ceph.conf-rw-r--r-- 1 root root 6211 Jul 3 19:57 ceph.conf.old
复制代码


故障总结


为了模拟故障,(size = 3, min_size = 2) 我们手动停止了 osd.1,然后查看 PG 状态,可见,它此刻的状态是 active+undersized+degraded,当一个 PG 所在的 OSD 挂掉之后,这个 PG 就会进入 undersized+degraded 状态,而后面的[0,2]的意义就是还有两个副本存活在 osd.0 和 osd.2 上, 并且这个时候客户端可以正常读写 IO。


3.1.3 总结


  • 降级就是在发生了一些故障比如 OSD 挂掉之后,Ceph 将这个 OSD 上的所有 PG 标记为 Degraded。

  • 降级的集群可以正常读写数据,降级的 PG 只是相当于小毛病而已,并不是严重的问题。

  • Undersized 的意思就是当前存活的 PG 副本数为 2,小于副本数 3,将其做此标记,表明存货副本数不足,也不是严重的问题。

3.2 Peered

3.2.1 说明


  • Peering 已经完成,但是 PG 当前 Acting Set 规模小于存储池规定的最小副本数(min_size)。


3.2.2 故障模拟


a. 停掉两个副本 osd.1,osd.0


$ systemctl stop ceph-osd@1$ systemctl stop ceph-osd@0
复制代码


b. 查看集群健康状态


$ bin/ceph health detailHEALTH_WARN 1 osds down; Reduced data availability: 4 pgs inactive; Degraded data redundancy: 26/39 objects degraded (66.667%), 20 pgs unclean, 20 pgs degraded; application not enabled on 1 pool(s)OSD_DOWN 1 osds down    osd.0 (root=default,host=ceph-xx-cc00) is downPG_AVAILABILITY Reduced data availability: 4 pgs inactive    pg 1.6 is stuck inactive for 516.741081, current state undersized+degraded+peered, last acting [2]    pg 1.10 is stuck inactive for 516.737888, current state undersized+degraded+peered, last acting [2]    pg 1.11 is stuck inactive for 516.737408, current state undersized+degraded+peered, last acting [2]    pg 1.12 is stuck inactive for 516.736955, current state undersized+degraded+peered, last acting [2]PG_DEGRADED Degraded data redundancy: 26/39 objects degraded (66.667%), 20 pgs unclean, 20 pgs degraded    pg 1.0 is undersized+degraded+peered, acting [2]    pg 1.1 is undersized+degraded+peered, acting [2]
复制代码


c. 客户端 IO 操作(夯住)


#读取对象到文件,夯住IO$ bin/rados -p test_pool get myobject  ceph.conf.old
复制代码


故障总结:


  • 现在 pg 只剩下 osd.2 上存活,并且 pg 还多了一个状态:peered,英文的意思是仔细看,这里我们可以理解成协商、搜索。

  • 这时候读取文件,会发现指令会卡在那个地方一直不动,为什么就不能读取内容了,因为我们设置的 min_size=2 ,如果存活数少于 2,比如这里的 1 ,那么就不会响应外部的 IO 请求。


d. 调整 min_size=1 可以解决 IO 夯住问题


#设置min_size = 1$ bin/ceph osd pool set test_pool min_size 1set pool 1 min_size to 1
复制代码


e. 查看集群监控状态


$ bin/ceph health detailHEALTH_WARN 1 osds down; Degraded data redundancy: 26/39 objects degraded (66.667%), 20 pgs unclean, 20 pgs degraded, 20 pgs undersized; application not enabled on 1 pool(s)OSD_DOWN 1 osds down    osd.0 (root=default,host=ceph-xx-cc00) is downPG_DEGRADED Degraded data redundancy: 26/39 objects degraded (66.667%), 20 pgs unclean, 20 pgs degraded, 20 pgs undersized    pg 1.0 is stuck undersized for 65.958983, current state active+undersized+degraded, last acting [2]    pg 1.1 is stuck undersized for 65.960092, current state active+undersized+degraded, last acting [2]    pg 1.2 is stuck undersized for 65.960974, current state active+undersized+degraded, last acting [2]
复制代码


f. 客户端 IO 操作


#读取对象到文件中$ ll -lh ceph.conf*-rw-r--r-- 1 root root 6.1K Jun 25 14:01 ceph.conf-rw-r--r-- 1 root root 6.1K Jul  3 20:11 ceph.conf.old-rw-r--r-- 1 root root 6.1K Jul  3 20:11 ceph.conf.old.1
复制代码


故障总结:


  • 可以看到,PG 状态 Peered 没有了,并且客户端文件 IO 可以正常读写了。

  • 当 min_size=1 时,只要集群里面有一份副本活着,那就可以响应外部的 IO 请求。


3.2.3 总结


  • Peered 状态我们这里可以将它理解成它在等待其他副本上线。

  • 当 min_size = 2 时,也就是必须保证有两个副本存活的时候就可以去除 Peered 这个状态。

  • 处于 Peered 状态的 PG 是不能响应外部的请求的并且 IO 被挂起。

3.3 Remapped

3.3.1 说明


  • Peering 完成,PG 当前 Acting Set 与 Up Set 不一致就会出现 Remapped 状态。


3.3.2 故障模拟


a. 停止 osd.x


$ systemctl stop ceph-osd@x
复制代码


b. 间隔 5 分钟,启动 osd.x


$ systemctl start ceph-osd@x
复制代码


c. 查看 PG 状态


$ ceph pg stat1416 pgs: 6 active+clean+remapped, 1288 active+clean, 3 stale+active+clean, 119 active+undersized+degraded; 74940 MB data, 250 GB used, 185 TB / 185 TB avail; 1292/48152 objects degraded (2.683%)$ ceph pg dump | grep remappeddumped all13.cd         0                  0        0         0       0         0    2        2      active+clean+remapped 2018-07-03 20:26:14.478665       9453'2   20716:11343    [10,23]         10 [10,23,14]             10       9453'2 2018-07-03 20:26:14.478597          9453'2 2018-07-01 13:11:43.2626053.1a         44                  0        0         0       0 373293056 1500     1500      active+clean+remapped 2018-07-03 20:25:47.885366  20272'79063  20716:109173     [9,23]          9  [9,23,12]              9  20272'79063 2018-07-03 03:14:23.960537     20272'79063 2018-07-03 03:14:23.9605375.f           0                  0        0         0       0         0    0        0      active+clean+remapped 2018-07-03 20:25:47.888430          0'0   20716:15530     [23,8]         23  [23,8,22]             23          0'0 2018-07-03 06:44:05.232179             0'0 2018-06-30 22:27:16.7784663.4a         45                  0        0         0       0 390070272 1500     1500      active+clean+remapped 2018-07-03 20:25:47.886669  20272'78385  20716:108086     [7,23]          7  [7,23,17]              7  20272'78385 2018-07-03 13:49:08.190133      7998'78363 2018-06-28 10:30:38.20199313.102        0                  0        0         0       0         0    5        5      active+clean+remapped 2018-07-03 20:25:47.884983       9453'5   20716:11334     [1,23]          1  [1,23,14]              1       9453'5 2018-07-02 21:10:42.028288          9453'5 2018-07-02 21:10:42.02828813.11d        1                  0        0         0       0   4194304 1539     1539      active+clean+remapped 2018-07-03 20:25:47.886535  20343'22439   20716:86294     [4,23]          4  [4,23,15]              4  20343'22439 2018-07-03 17:21:18.567771     20343'22439 2018-07-03 17:21:18.567771#2分钟之后查询$ ceph pg stat1416 pgs: 2 active+undersized+degraded+remapped+backfilling, 10 active+undersized+degraded+remapped+backfill_wait, 1401 active+clean, 3 stale+active+clean; 74940 MB data, 247 GB used, 179 TB / 179 TB avail; 260/48152 objects degraded (0.540%); 49665 kB/s, 9 objects/s recovering$ ceph pg dump | grep remappeddumped all13.1e8 2 0 2 0 0 8388608 1527 1527 active+undersized+degraded+remapped+backfill_wait 2018-07-03 20:30:13.999637 9493'38727 20754:165663 [18,33,10] 18 [18,10] 18 9493'38727 2018-07-03 19:53:43.462188 0'0 2018-06-28 20:09:36.303126
复制代码


d. 客户端 IO 操作


#rados读写正常rados -p test_pool put myobject /tmp/test.log
复制代码


3.3.3 总结


  • 在 OSD 挂掉或者在扩容的时候 PG 上的 OSD 会按照 Crush 算法重新分配 PG 所属的 osd 编号。并且会把 PG Remap 到别的 OSD 上去。

  • Remapped 状态时,PG 当前 Acting Set 与 Up Set 不一致。

  • 客户端 IO 可以正常读写。

3.4 Recovery

3.4.1 说明


  • 指 PG 通过 PGLog 日志针对数据不一致的对象进行同步和修复的过程。


3.4.2 故障模拟


a. 停止 osd.x


$ systemctl stop ceph-osd@x
复制代码


b. 间隔 1 分钟启动 osd.x


osd$ systemctl start ceph-osd@x
复制代码


c. 查看集群监控状态


$ ceph health detailHEALTH_WARN Degraded data redundancy: 183/57960 objects degraded (0.316%), 17 pgs unclean, 17 pgs degradedPG_DEGRADED Degraded data redundancy: 183/57960 objects degraded (0.316%), 17 pgs unclean, 17 pgs degraded    pg 1.19 is active+recovery_wait+degraded, acting [29,9,17]
复制代码


3.4.3 总结


  • Recovery 是通过记录的 PGLog 进行恢复数据的。

  • 记录的 PGLog 在 osd_max_pg_log_entries=10000 条以内,这个时候通过 PGLog 就能增量恢复数据。

3.5 Backfill

3.5.1 说明


  • 当 PG 的副本无非通过 PGLog 来恢复数据,这个时候就需要进行全量同步,通过完全拷贝当前 Primary 所有对象的方式进行全量同步。


3.5.2 故障模拟


a. 停止 osd.x


$ systemctl stop ceph-osd@x
复制代码


b. 间隔 10 分钟启动 osd.x


$ osd systemctl start ceph-osd@x
复制代码


c. 查看集群健康状态


$ ceph health detailHEALTH_WARN Degraded data redundancy: 6/57927 objects degraded (0.010%), 1 pg unclean, 1 pg degradedPG_DEGRADED Degraded data redundancy: 6/57927 objects degraded (0.010%), 1 pg unclean, 1 pg degraded    pg 3.7f is active+undersized+degraded+remapped+backfilling, acting [21,29] 
复制代码


3.5.3 总结


  • 无法根据记录的 PGLog 进行恢复数据时,就需要执行 Backfill 过程全量恢复数据。

  • 如果超过 osd_max_pg_log_entries=10000 条, 这个时候需要全量恢复数据。

3.6 Stale

3.6.1 说明


  • mon 检测到当前 PG 的 Primary 所在的 osd 宕机。

  • Primary 超时未向 mon 上报 pg 相关的信息(例如网络阻塞)。

  • PG 内三个副本都挂掉的情况。


3.6.2 故障模拟


a. 分别停止 PG 中的三个副本 osd, 首先停止 osd.23


$ systemctl stop ceph-osd@23
复制代码


b. 然后停止 osd.24


$ systemctl stop ceph-osd@24
复制代码


c. 查看停止两个副本 PG 1.45 的状态(undersized+degraded+peered)


$ ceph health detailHEALTH_WARN 2 osds down; Reduced data availability: 9 pgs inactive; Degraded data redundancy: 3041/47574 objects degraded (6.392%), 149 pgs unclean, 149 pgs degraded, 149 pgs undersizedOSD_DOWN 2 osds down    osd.23 (root=default,host=ceph-xx-osd02) is down    osd.24 (root=default,host=ceph-xx-osd03) is downPG_AVAILABILITY Reduced data availability: 9 pgs inactive    pg 1.45 is stuck inactive for 281.355588, current state undersized+degraded+peered, last acting [10]
复制代码


d. 在停止 PG 1.45 中第三个副本 osd.10


$ systemctl stop ceph-osd@10
复制代码


e. 查看停止三个副本 PG 1.45 的状态(stale+undersized+degraded+peered)


$ ceph health detailHEALTH_WARN 3 osds down; Reduced data availability: 26 pgs inactive, 2 pgs stale; Degraded data redundancy: 4770/47574 objects degraded (10.026%), 222 pgs unclean, 222 pgs degraded, 222 pgs undersizedOSD_DOWN 3 osds down    osd.10 (root=default,host=ceph-xx-osd01) is down    osd.23 (root=default,host=ceph-xx-osd02) is down    osd.24 (root=default,host=ceph-xx-osd03) is downPG_AVAILABILITY Reduced data availability: 26 pgs inactive, 2 pgs stale    pg 1.9 is stuck inactive for 171.200290, current state undersized+degraded+peered, last acting [13]    pg 1.45 is stuck stale for 171.206909, current state stale+undersized+degraded+peered, last acting [10]    pg 1.89 is stuck inactive for 435.573694, current state undersized+degraded+peered, last acting [32]    pg 1.119 is stuck inactive for 435.574626, current state undersized+degraded+peered, last acting [28]
复制代码


f. 客户端 IO 操作


#读写挂载磁盘IO 夯住ll /mnt/
复制代码


故障总结:


先停止同一个 PG 内两个副本,状态是 undersized+degraded+peered。


然后停止同一个 PG 内三个副本,状态是 stale+undersized+degraded+peered。


3.6.3 总结


  • 当出现一个 PG 内三个副本都挂掉的情况,就会出现 stale 状态。

  • 此时该 PG 不能提供客户端读写,IO 挂起夯住。

  • Primary 超时未向 mon 上报 pg 相关的信息(例如网络阻塞),也会出现 stale 状态。

3.7 Inconsistent

3.7.1 说明


  • PG 通过 Scrub 检测到某个或者某些对象在 PG 实例间出现了不一致


3.7.2 故障模拟


a. 删除 PG 3.0 中副本 osd.34 头文件


$ rm -rf /var/lib/ceph/osd/ceph-34/current/3.0_head/DIR_0/1000000697c.0000122c__head_19785300__3
复制代码


b. 手动执行 PG 3.0 进行数据清洗


$ ceph pg scrub 3.0instructing pg 3.0 on osd.34 to scrub
复制代码


c. 检查集群监控状态


$ ceph health detailHEALTH_ERR 1 scrub errors; Possible data damage: 1 pg inconsistentOSD_SCRUB_ERRORS 1 scrub errorsPG_DAMAGED Possible data damage: 1 pg inconsistent    pg 3.0 is active+clean+inconsistent, acting [34,23,1]
复制代码


d. 修复 PG 3.0


$ ceph pg repair 3.0instructing pg 3.0 on osd.34 to repair
#查看集群监控状态$ ceph health detailHEALTH_ERR 1 scrub errors; Possible data damage: 1 pg inconsistent, 1 pg repairOSD_SCRUB_ERRORS 1 scrub errorsPG_DAMAGED Possible data damage: 1 pg inconsistent, 1 pg repair pg 3.0 is active+clean+scrubbing+deep+inconsistent+repair, acting [34,23,1]
#集群监控状态已恢复正常$ ceph health detailHEALTH_OK
复制代码


故障总结:


当 PG 内部三个副本有数据不一致的情况,想要修复不一致的数据文件,只需要执行 ceph pg repair 修复指令,ceph 就会从其他的副本中将丢失的文件拷贝过来就行修复数据。


3.7.3 故障模拟


  • 当 osd 短暂挂掉的时候,因为集群内还存在着两个副本,是可以正常写入的,但是 osd.34 内的数据并没有得到更新,过了一会 osd.34 上线了,这个时候 osd.34 的数据是陈旧的,就通过其他的 OSD 向 osd.34 进行数据的恢复,使其数据为最新的,而这个恢复的过程中,PG 的状态会从 inconsistent ->recover -> clean,最终恢复正常。

  • 这是集群故障自愈一种场景。

3.8 Down

3.8.1 说明


  • Peering 过程中,PG 检测到某个不能被跳过的 Interval 中(例如该 Interval 期间,PG 完成了 Peering,并且成功切换至 Active 状态,从而有可能正常处理了来自客户端的读写请求),当前剩余在线的 OSD 不足以完成数据修复.


3.8.2 故障模拟


a. 查看 PG 3.7f 内副本数


$ ceph pg dump | grep ^3.7fdumped all3.7f         43                  0        0         0       0 494927872 1569     1569               active+clean 2018-07-05 02:52:51.512598  21315'80115  21356:111666  [5,21,29]          5  [5,21,29]              5  21315'80115 2018-07-05 02:52:51.512568      6206'80083 2018-06-29 22:51:05.831219
复制代码


b. 停止 PG 3.7f 副本 osd.21


$ systemctl stop ceph-osd@21
复制代码


c. 查看 PG 3.7f 状态


$ ceph pg dump | grep ^3.7fdumped all3.7f         66                  0       89         0       0 591396864 1615     1615 active+undersized+degraded 2018-07-05 15:29:15.741318  21361'80161  21365:128307     [5,29]          5     [5,29]              5  21315'80115 2018-07-05 02:52:51.512568      6206'80083 2018-06-29 22:51:05.831219
复制代码


d. 客户端写入数据,一定要确保数据写入到 PG 3.7f 的副本中[5,29]


$ fio -filename=/mnt/xxxsssss -direct=1 -iodepth 1 -thread -rw=read -ioengine=libaio -bs=4M -size=2G -numjobs=30 -runtime=200 -group_reporting -name=read-libaioread-libaio: (g=0): rw=read, bs=4M-4M/4M-4M/4M-4M, ioengine=libaio, iodepth=1...fio-2.2.8Starting 30 threadsread-libaio: Laying out IO file(s) (1 file(s) / 2048MB)Jobs: 5 (f=5): [_(5),R(1),_(5),R(1),_(3),R(1),_(2),R(1),_(1),R(1),_(9)] [96.5% done] [1052MB/0KB/0KB /s] [263/0/0 iops] [eta 00m:02s]                                                            s]read-libaio: (groupid=0, jobs=30): err= 0: pid=32966: Thu Jul  5 15:35:16 2018  read : io=61440MB, bw=1112.2MB/s, iops=278, runt= 55203msec    slat (msec): min=18, max=418, avg=103.77, stdev=46.19    clat (usec): min=0, max=33, avg= 2.51, stdev= 1.45     lat (msec): min=18, max=418, avg=103.77, stdev=46.19    clat percentiles (usec):     |  1.00th=[    1],  5.00th=[    1], 10.00th=[    1], 20.00th=[    2],     | 30.00th=[    2], 40.00th=[    2], 50.00th=[    2], 60.00th=[    2],     | 70.00th=[    3], 80.00th=[    3], 90.00th=[    4], 95.00th=[    5],     | 99.00th=[    7], 99.50th=[    8], 99.90th=[   10], 99.95th=[   14],     | 99.99th=[   32]    bw (KB  /s): min=15058, max=185448, per=3.48%, avg=39647.57, stdev=12643.04    lat (usec) : 2=19.59%, 4=64.52%, 10=15.78%, 20=0.08%, 50=0.03%  cpu          : usr=0.01%, sys=0.37%, ctx=491792, majf=0, minf=15492  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%     issued    : total=r=15360/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0     latency   : target=0, window=0, percentile=100.00%, depth=1Run status group 0 (all jobs):   READ: io=61440MB, aggrb=1112.2MB/s, minb=1112.2MB/s, maxb=1112.2MB/s, mint=55203msec, maxt=55203msec
复制代码


e. 停止 PG 3.7f 中副本 osd.29,并且查看 PG 3.7f 状态(undersized+degraded+peered)


#停止该PG副本osd.29systemctl stop ceph-osd@29 #查看该PG 3.7f状态为undersized+degraded+peeredceph pg dump | grep ^3.7fdumped all3.7f         70                  0      140         0       0 608174080 1623     1623 undersized+degraded+peered 2018-07-05 15:35:51.629636  21365'80169  21367:132165        [5]          5        [5]              5  21315'80115 2018-07-05 02:52:51.512568      6206'80083 2018-06-29 22:51:05.831219
复制代码


f. 停止 PG 3.7f 中副本 osd.5,并且查看 PG 3.7f 状态(undersized+degraded+peered)


#停止该PG副本osd.5$ systemctl stop ceph-osd@5 #查看该PG状态undersized+degraded+peered$ ceph pg dump | grep ^3.7fdumped all3.7f         70                  0      140         0       0 608174080 1623     1623 stale+undersized+degraded+peered 2018-07-05 15:35:51.629636  21365'80169  21367:132165        [5]          5        [5]              5  21315'80115 2018-07-05 02:52:51.512568      6206'80083 2018-06-29 22:51:05.831219
复制代码


g. 拉起 PG 3.7f 中副本 osd.21(此时的 osd.21 数据比较陈旧), 查看 PG 状态(down)


#拉起该PG的osd.21$ systemctl start ceph-osd@21 #查看该PG的状态down$ ceph pg dump | grep ^3.7fdumped all3.7f         66                  0        0         0       0 591396864 1548     1548                          down 2018-07-05 15:36:38.365500  21361'80161  21370:111729       [21]         21       [21]             21  21315'80115 2018-07-05 02:52:51.512568      6206'80083 2018-06-29 22:51:05.831219
复制代码


h. 客户端 IO 操作


#此时客户端IO都会夯住ll /mnt/
复制代码


故障总结:


首先有一个 PG 3.7f 有三个副本[5,21,29], 当停掉一个 osd.21 之后, 写入数据到 osd.5, osd.29。 这个时候停掉 osd.29, osd.5 ,最后拉起 osd.21。 这个时候 osd.21 的数据比较旧,就会出现 PG 为 down 的情况,这个时候客户端 IO 会夯住,只能拉起挂掉的 osd 才能修复问题。


3.8.3 结论


  • 典型的场景:A(主)、B、C

  • a. 首先 kill B

  • b. 新写入数据到 A、C

  • c. kill A 和 C

  • d. 拉起 B

  • 出现 PG 为 Down 的场景是由于 osd 节点数据太旧,并且其他在线的 osd 不足以完成数据修复。

  • 这个时候该 PG 不能提供客户端 IO 读写, IO 会挂起夯住。

作者信息

作者简介:李航,多年的底层开发经验,在高性能 nginx 开发和分布式缓存 redis cluster 有着丰富的经验,目前从事 Ceph 工作两年左右。


先后在 58 同城、汽车之家、优酷土豆集团工作。


目前供职于滴滴基础平台运维部-技术专家岗位 负责分布式 Ceph 集群开发及运维等工作。


个人主要关注的技术领域:高性能 Nginx 开发、分布式缓存、分布式存储。


2018-11-15 15:1412857

评论

发布
暂无评论
发现更多内容

堡垒机有硬件吗?推荐使用硬件堡垒机吗?

行云管家

云计算 网络安全 云服务 堡垒机

豆瓣评分9.0!《Java核心技术与面试》神作,已助1374人拿到Offer

做梦都在改BUG

Java java面试 Java八股文 Java面试题 Java面试八股文

面试官:在高并发情况,你是如何解决单用户超领优惠券问题的?

做梦都在改BUG

Java redis 高并发

从 Netflix 传奇看,结果导向的产品路线图如何制定?(下篇)

LigaAI

敏捷开发 研发管理 研发效能 it路线图 企业号 3 月 PK 榜

TiDB Operator备份TiDB集群到NFS持久卷

TiDB 社区干货传送门

集群管理 管理与运维 故障排查/诊断 安装 & 部署 备份 & 恢复

面试官:你了解Spring Security 权限控制吗?

做梦都在改BUG

Java spring spring security

小程序成生活“标配”,成互联网商业的重要阵地

没有用户名丶

小程序化

手写模拟Spring底层原理-Bean的创建与获取

京东科技开发者

spring 接口 aop 代码 bean

头一次见!阿里牛人上传的600页JVM垃圾优化笔记飙升GitHub榜首

做梦都在改BUG

Java 性能优化 JVM 垃圾回收

一天约了4个面试,复盘一下面试题和薪资福利

王中阳Go

Go 面试 面试题 简历优化 大厂突击

面试官:JVM是如何分配和回收堆外内存的?

做梦都在改BUG

Java JVM 垃圾回收

喜讯!华秋电子荣获第六届“高新杯”十大优秀企业奖

华秋电子

图数据库认证考试 NGCP 错题解析 vol.02:这 10 道题竟无一人全部答对

NebulaGraph

图数据库

接口优化的常见方案实战总结

京东科技开发者

批处理 预处理 企业号 3 月 PK 榜 接口优化 异步处理

全局视角看技术-Java多线程演进史

京东科技开发者

jdk 多线程 Thread 企业号 3 月 PK 榜

等保二级必须要上的设备有哪些?需要堡垒机吗?

行云管家

等保 堡垒机 等保二级

新兴应用场景层出不穷,电源管理芯片市场前景广阔

华秋电子

解决80%的工作场景?GitHub爆赞的Java高并发与集合框架,太赞了

做梦都在改BUG

Java 高并发 JUC JCF

TiDB Operator恢复持久卷上的备份文件

TiDB 社区干货传送门

集群管理 管理与运维 故障排查/诊断 安装 & 部署 备份 & 恢复

服务老是被攻击,如何设计一套比较安全的接口访问策略?

做梦都在改BUG

如何通过C#/VB.NET代码在Word中更改字体颜色

在下毛毛雨

C# .net word文档 字体 段落

中移链元交易功能对接说明

BSN研习社

Tapdata Cloud 基础课:新功能详解之「微信告警」,更及时的告警通知渠道

tapdata

数据库·

开发者进阶必备的9个Tips & Tricks!

SEAL安全

开发者 企业号 3 月 PK 榜 开发人员

再创佳绩!阿里云 4 篇论文入选顶会 FAST 2023

云布道师

阿里云 云存储

干货分享!PCBA元器件间距的可焊性设计

华秋电子

王者荣耀商城异地多活架构设计

Geek_7d539e

数据库日常实操优质文章分享(含Oracle、MySQL等) | 2023年2月刊

墨天轮

MySQL 数据库 oracle postgresql 性能优化

平安银行与易观千帆签约合作,加速数字用户资产增长

易观分析

金融 银行

云数据库TiDB试用初体验

TiDB 社区干货传送门

6.x 实践

软件测试/测试开发 | 功能测试转测试开发,该如何写简历?如何与其他竞争者中脱颖而出?

测试人

软件测试 自动化测试 测试开发

分布式存储系统Ceph之PG状态详解_软件工程_李航_InfoQ精选文章