Ceph中一些PG相关的状态说明和基本概念说明、故障模拟

2023-11-08

Ceph中一些PG相关的状态说明和基本概念说明

最近公司有个Ceph集群出了点问题,于是也参与了修复的过程,过程中最让人头疼的就是一堆不明所以的状态了,所以看了看文档,也找了一些参考,
整理了一下Ceph PG的一些状态以及相关的概念说明,做了一个中英文的对照版本:

Placement Group States(PG状态)

当检查一个集群的状态时(执行ceph -w或者ceph -s),Ceph会汇报当前PG的状态,每个PG会有一个或多个状态,最优的PG状态是active + clean
下面是所有PG状态的具体解释:

creating

Ceph is still creating the placement group.
Ceph 仍在创建PG。

activating

The placement group is peered but not yet active.
PG已经互联,但是还没有active。

active

Ceph will process requests to the placement group.
Ceph 可处理到此PG的请求。

clean

Ceph replicated all objects in the placement group the correct
number of times.
PG内所有的对象都被正确的复制了对应的份数。

down

A replica with necessary data is down, so the placement group is
offline.
一个包含必备数据的副本离线,所以PG也离线了。

scrubbing

Ceph is checking the placement group metadata for inconsistencies.
Ceph 正在检查PG metadata的一致性。

deep

Ceph is checking the placement group data against stored checksums.
Ceph 正在检查PG数据和checksums的一致性。

degraded

Ceph has not replicated some objects in the placement group the
correct number of times yet.
PG中的一些对象还没有被复制到规定的份数。

inconsistent

Ceph detects inconsistencies in the one or more replicas of an
object in the placement group (e.g. objects are the wrong size,
objects are missing from one replica *after* recovery finished,
etc.).
Ceph检测到PG中对象的一份或多份数据不一致(比如对象大学不一直,或者恢复成功后对象依然没有等)

peering

The placement group is undergoing the peering process
PG正在互联过程中。

repair

Ceph is checking the placement group and repairing any
inconsistencies it finds (if possible).
Ceph正在检查PG并且修复所有发现的不一致情况(如果有的话)。

recovering

Ceph is migrating/synchronizing objects and their replicas.
Ceph正在迁移/同步对象和其副本。

forced_recovery

High recovery priority of that PG is enforced by user.
用户指定的PG高优先级恢复

recovery_wait

The placement group is waiting in line to start recover.
PG正在等待恢复被调度执行。

recovery_toofull

A recovery operation is waiting because the destination OSD is over
its full ratio.
恢复操作因为目标OSD容量超过指标而挂起。

recovery_unfound

Recovery stopped due to unfound objects.
恢复因为没有找到对应对象而停止。

backfilling

Ceph is scanning and synchronizing the entire contents of a
placement group instead of inferring what contents need to be
synchronized from the logs of recent operations. Backfill is a
special case of recovery.
Ceph正常扫描并同步整个PG的数据,而不是从最近的操作日志中推断需要同步的数据,Backfill(回填)是恢复的一个特殊状态。

forced_backfill

High backfill priority of that PG is enforced by user.
用户指定的高优先级backfill。

backfill_wait

The placement group is waiting in line to start backfill.
PG正在等待backfill被调度执行。

backfill_toofull

A backfill operation is waiting because the destination OSD is over
its full ratio.
backfill操作因为目标OSD容量超过指标而挂起。

backfill_unfound

Backfill stopped due to unfound objects.
Backfill因为没有找到对应对象而停止。

incomplete

Ceph detects that a placement group is missing information about
writes that may have occurred, or does not have any healthy copies.
If you see this state, try to start any failed OSDs that may contain
the needed information. In the case of an erasure coded pool
temporarily reducing min\_size may allow recovery.
Ceph 探测到某一PG可能丢失了写入信息,或者没有健康的副本。如果你看到了这个状态,尝试启动有可能包含所需信息的失败OSD,
如果是erasure coded pool的话,临时调整一下`min_size`也可能完成恢复。

stale

The placement group is in an unknown state - the monitors have not
received an update for it since the placement group mapping changed.
PG状态未知,从PG mapping更新后Monitor一直没有收到更新。

remapped

The placement group is temporarily mapped to a different set of OSDs
from what CRUSH specified.
PG被临时分配到了和CRUSH所指定的不同的OSD上。

undersized

The placement group has fewer copies than the configured pool
replication level.
该PG的副本数量小于存储池所配置的副本数量。

peered

The placement group has peered, but cannot serve client IO due to
not having enough copies to reach the pool\'s configured min\_size
parameter. Recovery may occur in this state, so the pg may heal up
to min\_size eventually.
PG已互联,但是不能向客户端提供服务,因为其副本数没达到本存储池的配置值( min_size 参数)。
在此状态下恢复会进行,所以此PG最终能达到 min_size 。

snaptrim

Trimming snaps.
正在对快照做Trim操作。

snaptrim_Wait

Queued to trim snaps.
Trim操作等待被调度执行

snaptrim_Error

Error stopped trimming snaps.
Trim操作因为错误而停止

Placement Group Concepts(PG相关概念)

When you execute commands like ceph -wceph osd dump, and other
commands related to placement groups, Ceph may return values using some
of the following terms:
当执行诸如ceph -wceph osd dump及其他和归置组相关的命令时, Ceph 会返回下列术语:

Peering (建立互联)

The process of bringing all of the OSDs that store a Placement Group
(PG) into agreement about the state of all of the objects (and their
metadata) in that PG. Note that agreeing on the state does not mean
that they all have the latest contents.
表示所有存储PG数据的OSD达成对PG中所有对象(和元数据)共识的过程。
需要注意的是达成共识并不代表他们都拥有最新的数据。

Acting Set (在任集合)

The ordered list of OSDs who are (or were as of some epoch)
responsible for a particular placement group.
一个OSD的有序集合,他们为一个PG(或者一些版本)负责。

Up Set (当选集合)

The ordered list of OSDs responsible for a particular placement
group for a particular epoch according to CRUSH. Normally this is
the same as the *Acting Set*, except when the *Acting Set* has been
explicitly overridden via `pg_temp` in the OSD Map.
一列有序OSD ,它们依据 CRUSH 算法为某一PG的特定元版本负责。
它通常和*Acting Set*相同,除非*Acting Set*被OSD map中的`pg_temp`显式地覆盖了。

Current Interval or Past Interval

A sequence of OSD map epochs during which the *Acting Set* and *Up
Set* for particular placement group do not change.
某一PG所在*Acting Set*和*Up Set*未更改时的一系列OSD map元版本。

Primary (主 OSD)

The member (and by convention first) of the *Acting Set*, that is
responsible for coordination peering, and is the only OSD that will
accept client-initiated writes to objects in a placement group.
*Acting Set*的成员(按惯例为第一个),它负责协调互联,并且是PG内惟一接受客户端初始写入的OSD。

Replica (副本 OSD)

A non-primary OSD in the *Acting Set* for a placement group (and who
has been recognized as such and *activated* by the primary).
PG的*Acting Set*内不是主OSD的其它OSD ,它们被同等对待、由主OSD激活。

Stray (彷徨 OSD)

An OSD that is not a member of the current *Acting Set*, but has not
yet been told that it can delete its copies of a particular
placement group.
不在PG的当前*Acting Set*中,但是还没有被告知要删除其副本的OSD。

Recovery (恢复)

Ensuring that copies of all of the objects in a placement group are
on all of the OSDs in the *Acting Set*. Once *Peering* has been
performed, the *Primary* can start accepting write operations, and
*Recovery* can proceed in the background.
确保*Acting Set*内、PG中的所有对象的副本都存在于所有OSD上。
一旦互联完成,主OSD就以接受写操作,且恢复进程可在后台进行。

PG Info (PG 信息)

Basic metadata about the placement group\'s creation epoch, the
version for the most recent write to the placement group, *last
epoch started*, *last epoch clean*, and the beginning of the
*current interval*. Any inter-OSD communication about placement
groups includes the *PG Info*, such that any OSD that knows a
placement group exists (or once existed) also has a lower bound on
*last epoch clean* or *last epoch started*.
基本元数据,关于PG创建元版本、PG的最新写版本、最近的开始元版本(last epoch started)、
最近的干净元版本(last epoch clean)、和当前间隔(current interval)的起点。 
OSD间关于PG的任何通讯都包含PG Info,这样任何知道PG存在(或曾经存在)的OSD也必定有last epoch clean或last epoch started的下限。

PG Log (PG 日志)

A list of recent updates made to objects in a placement group. Note
that these logs can be truncated after all OSDs in the *Acting Set*
have acknowledged up to a certain point.
PG内对象的一系列最近更新。需要注意的是这些日志在*Acting Set*内的所有OSD确认更新到某点后可以删除。

Missing Set (缺失集合)

Each OSD notes update log entries and if they imply updates to the
contents of an object, adds that object to a list of needed updates.
This list is called the *Missing Set* for that `<OSD,PG>`.
每个OSD都会记录更新日志,而且如果它们包含对象内容的更新,
会把那个对象加入一个待更新列表,这个列表叫做那个`<OSD,PG>`的*Missing Set*。

Authoritative History (权威历史)

A complete, and fully ordered set of operations that, if performed,
would bring an OSD\'s copy of a placement group up to date.
一个完整、完全有序的操作集合,如果再次执行,可把一个OSD上的PG副本还原到最新。

Epoch (元版本)

A (monotonically increasing) OSD map version number
一个(单调递增的)OSD map版本号。

Last Epoch Start (最新起始元版本)

The last epoch at which all nodes in the *Acting Set* for a
particular placement group agreed on an *Authoritative History*. At
this point, *Peering* is deemed to have been successful.
 一最新元版本,在这点上,PG所对应*Acting Set*内的所有节点都对权威历史达成了一致、
 并且互联被认为成功了。

up_thru (领导拍板)

Before a *Primary* can successfully complete the *Peering* process,
it must inform a monitor that is alive through the current OSD map
*Epoch* by having the monitor set its *up\_thru* in the osd map.
This helps *Peering* ignore previous *Acting Sets* for which
*Peering* never completed after certain sequences of failures, such
as the second interval below:

-   *acting set* = \[A,B\]
-   *acting set* = \[A\]
-   *acting set* = \[\] very shortly after (e.g., simultaneous
    failure, but staggered detection)
-   *acting set* = \[B\] (B restarts, A does not)
主OSD要想成功完成互联,它必须通过当前OSD map元版本通知一个Monitor,让此Monitor在OSD map中设置其up_thru。
这会使互联进程忽略之前的*Acting Set*,因为它经历特定顺序的失败后一直不能互联,比如像下面的第二周期:

acting set = [A,B]
acting set = [A]
acting set = [] 之后很短时间(例如同时失败、但探测是交叉的)
acting set = [B] ( B 重启了、但 A 没有)

Last Epoch Clean (最新干净元版本)

The last *Epoch* at which all nodes in the *Acting set* for a
particular placement group were completely up to date (both
placement group logs and object contents). At this point, *recovery*
is deemed to have been completed.
最近的Epoch,这时某一特定PG所在*Acting Set*内的所有节点都全部更新了(包括PG日志和对象内容)。
在这点上,恢复被认为已完成。

3.故障模拟:

a. 停止osd.1

$ systemctl stop ceph-osd@1

b. 查看PG状态

$ bin/ceph pg stat
20 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 detail
HEALTH_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 down
PG_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 detail
HEALTH_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 down
PG_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 1
set pool 1 min_size to 1

e. 查看集群监控状态

$ bin/ceph health detail
HEALTH_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 down
PG_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 stat
1416 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 remapped
dumped all
13.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.262605
3.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.960537
5.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.778466
3.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.201993
13.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.028288
13.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 stat
1416 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 remapped
dumped all
13.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 detail
HEALTH_WARN Degraded data redundancy: 183/57960 objects degraded (0.316%), 17 pgs unclean, 17 pgs degraded
PG_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 detail
HEALTH_WARN Degraded data redundancy: 6/57927 objects degraded (0.010%), 1 pg unclean, 1 pg degraded
PG_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 detail
HEALTH_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 undersized
OSD_DOWN 2 osds down
    osd.23 (root=default,host=ceph-xx-osd02) is down
    osd.24 (root=default,host=ceph-xx-osd03) is down
PG_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 detail
HEALTH_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 undersized
OSD_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 down
PG_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.0
instructing pg 3.0 on osd.34 to scrub

c. 检查集群监控状态

$ 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 inconsistent
    pg 3.0 is active+clean+inconsistent, acting [34,23,1]

d. 修复PG 3.0

$ ceph pg repair 3.0
instructing pg 3.0 on osd.34 to repair

#查看集群监控状态
$ ceph health detail
HEALTH_ERR 1 scrub errors; Possible data damage: 1 pg inconsistent, 1 pg repair
OSD_SCRUB_ERRORS 1 scrub errors
PG_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 detail
HEALTH_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.7f
dumped all
3.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.7f
dumped all
3.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-libaio
read-libaio: (g=0): rw=read, bs=4M-4M/4M-4M/4M-4M, ioengine=libaio, iodepth=1
...
fio-2.2.8
Starting 30 threads
read-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=1
Run 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.29
systemctl stop ceph-osd@29

#查看该PG 3.7f状态为undersized+degraded+peered
ceph pg dump | grep ^3.7f
dumped all
3.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.7f
dumped all
3.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.7f
dumped all
3.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会挂起夯住。

 

本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

Ceph中一些PG相关的状态说明和基本概念说明、故障模拟 的相关文章

  • NSSearchPathForDirectoriesInDomains 和持久数据的问题

    根据建议 我们使用以下代码来检索用户文档的路径 NSArray paths NSSearchPathForDirectoriesInDomains NSDocumentDirectory NSUserDomainMask YES NSStr
  • 等待由外部配置程序“pd.csi.storage.gke.io”创建或由系统管理员手动创建卷。 Windows 迷你库

    我创建了一个 PVC 然后尝试扩大卷声明的大小 卷扩展设置为 true 如下 minikube kubectl get sc NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOL
  • Html 5 本地存储在 Firefox 中不持久

    我做了一个简单的功能 localStorage setItem foo bar alert localStorage getItem foo 如果我像这样运行它就可以了 如果我在运行一次后删除第一行并且只允许这个 alert localSt
  • bash——在运行之间存储变量的更好方法?

    我制作了一个 bash 脚本 我使用 crontab 每小时运行一次 并且我需要存储一个变量 以便下次运行它时可以访问它 该脚本每次运行时都会更改变量 因此我无法对其进行硬编码 现在我将其写入 txt 文件 然后读回 还有比这更好的方法吗
  • 访问 Android 上先前安装创建的文件 - 范围存储 Android 11

    我正在使用 LibGDX 开发一个带有预设管理器的音乐应用程序 该管理器使用 LibGDX 的 FileHandle 来管理文件和目录 在我更新到 Android 11 API 30 之前 此功能一直运行良好 现在由于 Android 新的
  • Android 外部存储与 SD 卡

    阅读有关存储文件的 Android 文档后 我发现外部存储可以包括可移动 SD 卡和设备内部存储 即不可移动 选择将文件保存到外部存储时 是否可以区分可移动存储和不可移动存储 我认为您无法可靠地区分内部和外部 SD 存储 乍一看 您似乎可以
  • 有没有办法确定应用程序在 iOS 中使用的磁盘空间量?

    我看过很多关于如何获取iOS设备有多少可用空间 或者iOS设备有多少可用空间的帖子 但是有没有办法确定应用程序本身使用了多少空间 包括应用程序本身及其所有资源 文档 缓存 等 这与在 设置 gt 常规 gt iPhone 存储 中看到的值相
  • 处理 JSON 对象的最佳方法是什么?

    我有一个代表 JSON feed 的大字符串 我的应用程序从远程网络服务下载此提要 问题 1 下载 JSON feed 后 我应该将其存储在哪里 现在我将其存储在应用程序首选项中并且工作正常 我只是感兴趣是否有任何理由不这样做 或者是否有更
  • USB 存储设备的无代码 kext

    在一个项目中 我最近尝试通过 osx 10 9 5 上的 libusb 访问 USB 存储设备 但显然一些默认驱动程序声称该设备 我无法访问它 当我尝试通过 libusb 访问它时 它返回我有 权限不足 当我在 Ubuntu 中执行 jav
  • 具有大量数据的 ec2 上 cassandra 设置的最佳实践

    我正在进行从物理机到 ec2 实例的大规模迁移 截至目前 我有 3 个 x large 节点 每个节点都有 4 个实例存储驱动器 raid 0 1 6TB 设置完后 我记得 实例存储卷上的数据仅在关联的 Amazon EC2 实例的生命周期
  • 网站通过文档上传会暴露哪些安全漏洞?

    我是文档存储空间的新手 我还不确定我在做什么 但在开始之前我想知道当允许文档上传时可能存在的安全威胁以及清理数据的最佳方法是什么 我正在使用 PHP 并且允许使用图像 word 文档 pdf excel 文档等 这是一个好的解决方案吗 ht
  • 清除网站的存储持久标志

    我正在使用navigator storage persist Chrome 上的 API 并已成功将其设置为true 但我希望 至少为了测试 能够清除设置放回false 据我所知 API 定义不包含需要清除的方法或标志 看https dev
  • 在 C# 中序列化和存储对象的最简单方法?

    我正在寻找一个简单的解决方案来序列化和存储包含配置 应用程序状态和数据的对象 它是一个简单的应用程序 数据不多 速度不是问题 我希望它正在进行中 我希望它在文本编辑器中比在 xml 中更容易编辑 我找不到任何可以在进程中处理它的 net 文
  • Android 阻止将照片保存在 DCIM/公共文件夹中

    我正在开发一个 Android 应用程序 用户单击按钮后可以拍照 这张照片将通过以下方法保存到内部包存储 data data package private String saveToInternalSorage Bitmap bitmap
  • 在数据库中保存 base64 字符串是一个好习惯吗?

    我正在开发一个 Android 应用程序 用户可以将图像发送到我的网络服务 目前 在我的 WebService 上 我得到一个 Base64 字符串并将其保存在数据库的表中 我的问题 这是一个好的做法吗 因为据我所知 Base64 字符串是
  • 如何正确获取外置SD卡路径?

    我面临着获取某些 Android 设备上安装的外部 SD 卡路径的众所周知的问题 看这个问题 https stackoverflow com questions 11281010 how can i get external sd card
  • 以编程方式截取屏幕截图不会捕获 surfaceVIew 的内容

    我有一个应用程序 我希望能够捕获屏幕截图 布局的背景是一个 SurfaceView 显示来自后置摄像头的视频 下面的代码可以截图 但是surfaceView的内容保存为黑色 这是代码 btn setOnClickListener new O
  • Laravel 5.3 存储和读取文件目录

    目前正在尝试处理文件 但很难弄清楚将它们放在哪里以及如何在列表中读回它们 我尝试过将一些测试文件放入 files array dir opendir asset files open the cwd also do an err check
  • 使用 Android NDK 将文件写入 SD 卡以外的位置?

    除了SD卡之外 还有其他方法可以将文件写入其他位置吗 我在文件系统上尝试了许多不同的路径 但 fopen 总是返回 NULL 除了我在 sdcard 内写入 读取的任何文件 还有其他相当于
  • S3 的 Rails 回形针默认图像

    我尝试在应用程序中使用default url 但我使用S3 存储图像 我不确定我需要在那里输入什么 URL 或者我是否必须创建一个假图像才能将所有内容放在那里 由于我的图像总是通过 S3 渲染 所以我不知道如果我只是在公共文件夹中放入一些默

随机推荐

  • 一个用于拷贝文件并判断是否拷贝成功的批处理文件

    echo off chcp 65001 copy E opencv build x64 vc15 bin opencv videoio ffmpeg420 64 dll windir set err ERRORLEVEL IF err 1
  • pear文件利用 (远程文件下载、生成配置文件、写配置文件) 从一道题看——CTFshow私教 web40

    web40 考点 pear文件包含 pear是PHP的一个扩展 条件 1 有文件包含点 2 开启了pear扩展 可以当他是一个框架 3 配置文件中register argc argv 设置为On 而默认为Off SERVER argv 生效
  • Vue脚手架的创建步骤

    vue cli脚手架 案例一 案例二 一 脚手架简介 Vue脚手架是Vue官方提供的标准化开发工具 开发平台 它提供命令行和UI界面 方便创建vue工程 配置第三方依赖 编译vue工程 1 webpack 前端项目工程化的标志之一就是引入了
  • Robot Arm 机械臂源码解析

    Robot Arm 机械臂源码解析 说明 Robot Arm是我复刻 也是玩的第一款机械臂 用的是三自由度的结构 你可以理解为了三个电机 三轴有自己的一些缺陷 相比于六轴机械臂而言因为结构的缺陷 不能达到空间内的一些点 这些点又叫做奇异点
  • Mybatis Plus入门

    MyBatis Plus介绍 MyBatis Plus 简称MP 是国内人员开发的 MyBatis 增强工具 在 MyBatis 的基础上只做增强不做改变 为简化开发 提高效率而生 特征 无侵入 Mybatis Plus 在 Mybatis
  • 过年不再被逼相亲——我用python给亲戚展示2022的相亲数据

    人生苦短 我用Python 这不是快过年了吗 又到了一年一度的亲戚大考验环节 没对象的他们会问你 找对象了吗 你要是学计算机专业的 他们会问你 会修电脑吗 出去学了点啥他们也会要求 才艺展示一下 我相信大家都躲不过去 既然躲不过去 那直接上
  • 主力吸筹猛攻指标源码_成功率90%以上【主力吸筹+买点提示+使用方法】通达信指标公式源码...

    成功率 90 以上 主力吸筹 买点提示 使用方法 使用方法 当指标出现红绿柱时就要开始关注 未来几天如果紫线上穿黄线 即是买点 紫 线穿过黄线的当天即可买入 此指标成功率极高 90 COLORBLUE VAR1 REF LOW OPEN C
  • 第6章 计算机的运算方法

    6 1无符号数和有符号数 6 1 1无符号数 寄存器位数反映无符号数的表示范围 6 1 2有符号数 1 机器数与真值 真值 带符号的数 机器数 符号数字化的数 2 原码表示法 整数 x 原是n 1位 用逗号将符号位和数值部分分隔开 小数 用
  • 6s微信连接不上服务器失败是什么原因,6s手机微信打不开怎么回事

    很多使用6s手机的用户反应 微信打不开一直显示正在载入怎么办 下面由学习啦小编为你整理了6s手机微信打不开怎么回事的相关方法 希望对你有帮助 6s手机微信打不开解决方法 如图所示 右下角的微信变成这样子 下方显示 正在载入 无法打开 我们首
  • Docker 安装 Nginx

    拉取镜像 docker pull nginx 启动测试 docker run d p 80 80 nginx p 80 80 端口进行映射 将本地 80 端口映射到容器内部的 80 端口 d nginx 设置容器在在后台一直运行 访问主机
  • c++ set容器

    容器分类 1 顺序容器 2 关联容器 3 无序 散列 容器 vector 向量 连续存储的元素 list 链表 由节点组成的双向链表 每个节点包含着一个元素 forward list 单向链表 deque 双队列 由连续存储的指向不同元素的
  • Qt: multiple definition of XXX

    使用Qt编译源文件时出现很多multiple definition of XXX的报错 可能原因是在多次包含global h时重复定义了变量和函数 但检查过代码后 发现并不存在重复定义的变量和函数 这时 只需要清除项目编译 o文件 重新构建
  • 【云原生之Docker实战】使用docker部署家庭DOS游戏服务器

    云原生之Docker实战 使用docker部署家庭DOS游戏服务器 一 DOS游戏网页版介绍 二 检查宿主机系统版本 三 检查本地docker环境 1 检查docker服务状态 2 检查docker版本 四 下载oldiy dosgame
  • C语言入门(基础二)

    延续上作 本篇博客带大家继续入门C语言 运算符 C语言三大结构 顺序结构 选择结构 循环语句 运算符 C语言为我们提供了很多的运算符 有单目运算符 双目运算符和三目运算符 这里的一目二目三目指的是操作的对象个数 我们可以使用这些运算符来解决
  • Kotlin 编程实战

    code小生 一个专注大前端领域的技术平台 公众号回复Android加入安卓技术群 导读 Kotlin诞生于2011年 开源于2012年 吸收了Java等语言的优良特性 提供了令人惊艳的编程体验 是编程语言界名副其实的 后浪 欢迎来到Kot
  • TypeError: load_state_dict() missing 1 required positional argument: ‘state_dict‘

    记录最近遇到的小bug 希望能够帮助到和我有类似错误的你 1 TypeError parameters missing 1 required positional argument self 这里是用如下的方法查看model的参数量 n p
  • [工业互联-10]:PLC入门简介

    目录 前言 PLC的用途 PLC的特点 PLC的分类 1 按PLC的控制规模分类 2 按PLC的控制性能分类 3 按PLC的结构分类 PLC的技术指标 1 硬件指标 2 软件指标 3 主要性能指标介绍 1 存储容量 2 输入 输出 I O
  • 在线观看北京奥运会直播 在网上看奥运会直播

    2008年北京奥运会开幕明天就来了 本次奥运会的赛事大多是在白天进行的 虽然CCTV拿出7个频道为本次奥运直播 但是对于大多数上班族 白天的 上班时间通过电视来看奥运直播是不太可能的 还好现在有网络直播 只要可以上网 就可以第一时间在线观看
  • gym102263 problem J Thanos Power (dp)

    链接 题意 给出一个大数 有两种操作 加 1 0 x 10 x 10x和减 1 0
  • Ceph中一些PG相关的状态说明和基本概念说明、故障模拟

    Ceph中一些PG相关的状态说明和基本概念说明 最近公司有个Ceph集群出了点问题 于是也参与了修复的过程 过程中最让人头疼的就是一堆不明所以的状态了 所以看了看文档 也找了一些参考 整理了一下Ceph PG的一些状态以及相关的概念说明 做