ceph PG状态的示例分析

这篇文章主要介绍ceph PG状态的示例分析，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！

当CRUSH分配安置组的OSD，它主要盯在泳池副本的数量和分配安置组到OSDS，每个副本都会被分配到不同的OSD等。例如，如果池需要三个副本放置组，CRUSH可能将他们分配到 osd.1 osd.2和osd.3。CRUSH其实是一个伪随机分配，它考虑CRUSH图中设置的故障域，所以你很少会看到在一个大集群中，布置组被分配到最近的邻居的OSD。我们指到设定的OSD应包含代理设置一个特定的安置组的副本。在某些情况下，代理设置OSD挂掉或以其他方式无法对安置组对象的服务请求。出现这种情况时，不要惊慌。常见的例子包括：

• 您正在添加或删除OSD。然后，CRUSH重新分配安置组给其他的OSD从而改变组成的代理设置和“回填”的过程中的数据迁移。

• 一个OSD 被restared，现在恢复。

• 一个正在执行动作的OSD挂掉，或无法接收服务请求，另一个的OSD临时使用其职责。

Ceph processes a client request using the Up Set, which is the set of OSDs that will actually handle the requests. In most cases, the Up Set and the Acting Set are virtually identical. When they are not, it may indicate that Ceph is migrating data, an OSD is recovering, or that there is a problem (i.e., Ceph usually echoes a “HEALTH WARN” state with a “stuck stale” message in such scenarios).

To retrieve a list of placement groups, execute:

Ceph的处理的客户端请求，使用的Up Set，这是一组，将实际处理请求的OSD。在大多数情况下，Up Set和the Acting Set，实际上是相同的。当他们都不是这种情况时，它可能表明Ceph的数据迁移，OSD正在恢复，或者说是一个问题（即，通常Ceph响应消息“HEALTH WARN”与“stuck stale”的消息）。

要检索布置组的列表，执行：

ceph pg dump

要查看它的OSD内的代理设置或最多设置安置组，执行：

ceph pg map {pg-num}

结果应该包括：osdmap的epoch（eNNN），安置组号码（{PG-NUM}），处于Up Set的OSDS和处于the acting set的OSDS。

osdmap eNNN pg {pg-num} -> up [0,1,2] acting [0,1,2]

PG中OSD确定代码主要为OSDMap::pg_to_osds、OSDMap::pg_to_up_acting_osds，在OSD.cc中创建、装载PG时都有调用

1. Creating

创建存储池时,它会创建指定数量的归置组。ceph 在创建一或多个归置组时会显示 creating;创建完后,在其归置组的 Acting Set 里的 OSD 将建立互联;一旦互联完成,归置组状态应该变为 active+clean,意思是ceph 客户端可以向归置组写入数据了。

2. peering

ceph 为归置组建立互联时,会让存储归置组副本的 OSD 之间就其中的对象和元数据状态达成一致。ceph 完成了互联,也就意味着存储着归置组的 OSD 就其当前状态达成了一致。然而,互联过程的完成并不能表明各副本都有了数据的最新版本。

3. active

ceph 完成互联进程后,一归置组就可变为 active。active 状态通常意味着在主归置组和副本中的数据都可以读写。

4. clean

某一归置组处于 clean 状态时,主 OSD 和副本 OSD 已成功互联,并且没有偏离的归置组。ceph 已把归置组中的对象复制了规定次数。

5. degraded

当客户端向主 OSD 写入数据时,由主 OSD 负责把副本写入其余复制 OSD。主 OSD 把对象写入复制 OSD 后,在没收到成功完成的确认前,主 OSD 会一直停留在 degraded 状态。
归置组状态可以是 active+degraded 状态,原因在于一 OSD 即使没所有对象也可以处于 active 状态。如果一OSD 挂了,ceph 会把相关的归置组都标记为 degraded;那个 OSD 重生后,它们必须重新互联。然而,如果归置组仍处于 active 状态,即便它处于 degraded 状态,客户端还可以向其写入新对象。
如果一 OSD 挂了,且 degraded 状态持续,ceph 会把 down 的 OSD 标记为在集群外(out)、并把那些 down 掉的 OSD 上的数据重映射到其它 OSD。从标记为 down 到 out 的时间间隔由 mon osd down out interval 控制,默认是 300 秒。
归置组也会被降级(degraded),因为归置组找不到本应存在于归置组中的一或多个对象,这时,你不能读或写找不到的对象,但仍能访问其它位于降级归置组中的对象。

6. recovering

ceph 被设计为可容错,可抵御一定规模的软、硬件问题。当某 OSD 挂了(down)时,其内容版本会落后于归置组内的其它副本;它重生(up)时,归置组内容必须更新,以反映当前状态;在此期间,OSD 在recovering 状态。
恢复并非总是这些小事,因为一次硬件失败可能牵连多个 OSD。比如一个机柜的网络交换机失败了,这会导致多个主机落后于集群的当前状态,问题解决后每一个 OSD 都必须恢复。
ceph 提供了很多选项来均衡资源竞争,如新服务请求、恢复数据对象和恢复归置组到当前状态。osd recovery delay start 选项允许一 OSD 在开始恢复进程前,先重启、重建互联、甚至处理一些重放请求;osd recovery threads 选项限制恢复进程的线程数,默认为 1 线程;osd recovery thread timeout 设置线程超时,因为多个OSD 可能交替失败、重启和重建互联;osd recovery max active 选项限制一 OSD 最多同时接受多少请求,以防它压力过大而不能正常服务;osd recovery max chunk 选项限制恢复数据块尺寸,以防网络拥塞。

7. back filling

有新 OSD 加入集群时,CRUSH 会把现有集群内的归置组重分配给它。强制新 OSD 立即接受重分配的归置组会使之过载,用归置组回填可使这个过程在后台开始。回填完成后,新 OSD 准备好时就可以对外服务了。

8. remapped

某一归置组的 Acting Set 变更时,数据要从旧集合迁移到新的。主 OSD 要花费一些时间才能提供服务,所以它可以让老的主 OSD 持续服务、直到归置组迁移完。数据迁移完后,主 OSD 会映射到新 acting set。

9. stale

虽然 ceph 用心跳来保证主机和守护进程在运行,但是 ceph-osd 仍有可能进入 stuck 状态,它们没有按时报告其状态(如网络瞬断)。默认,OSD 守护进程每半秒(0.5)会一次报告其归置组、出流量、引导和失败统计
状态,此频率高于心跳阀值。如果一归置组的主 OSD 所在的 acting set 没能向监视器报告、或者其它监视器已经报告了那个主 OSD 已 down,监视器们就会把此归置组标记为 stale。启动集群时,会经常看到 stale 状态,直到互联完成。集群运行一阵后,如果还能看到有归置组位于 stale 状态,就说明那些归置组的主 OSD 挂了(down)、或没在向监视器报告统计信息。
二、找出故障归置组

一般来说,归置组卡住时 ceph 的自修复功能往往无能为力,卡住的状态细分为:

1. unclean

不干净:归置组里有些对象的复制数未达到期望次数,它们应该在恢复中。

2. inactive

不活跃:归置组不能处理读写,因为它们在等着一个持有最新数据的 OSD 再次进入 up 状态。

3. stale

发蔫:归置组们处于一种未知状态,因为存储它们的 OSD 有一阵子没向监视器报告了(由 mon osdreport timeout 配置)。

以上是“ceph PG状态的示例分析”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注亿速云行业资讯频道！