带你读《存储漫谈Ceph原理与实践》第二章Ceph 架构2.3Ceph 的归置组(一)

简介: 《存储漫谈Ceph原理与实践》第二章Ceph 架构2.3Ceph 的归置组

Ceph存储系统使用的 CRUSH算法在一致性 Hash 算法的基础上充分考虑了多副本、故障域隔离等约束,尽量减少集群在故障场景下的数据迁移量,实现这一目标的关键举措   即为 PG逻辑概念的引入。

前文提到 Ceph可以理解为对 RADOS 对象存储系统的二次封装,Ceph中所有的用户数据都被抽象成多个Object,如果 Ceph存储系统以 Object 为追踪目标,那么要追踪的单元个体数量就太多了,不仅会消耗大量的计算资源,而且在一个有数以亿计对象(EB级存储集群)的系统中直接追踪对象的位置及其元数据信息也是完全不现实的。Ceph引进 PG逻辑概念,将一系列的Object聚合到 PG里,并将 PG 映射到一系列的OSD 上去。系统中PG数量远远小于 Object 数量,存储系统以PG 为存储单元个体,直接追踪PG 状态,比较好地处理了性能和可扩展性的界限。

PG的引入也会增加一些系统资源开销,如 PG 逻辑的处理会直接消耗存储节点的部分CPU和内存,增大 PG的数量会增加存储系统 Peering状态处理的数量。

2.3.1     PG数量的选择

上述分析可以看出PG   是用户数据切片Object与真实提供存储空间的存储介质

OSD守护进程)之间的纽带。Ceph存储系统需要设置较为合理的 PG数量,过少的PG数量会导致集群 peer过程太慢,数据迁移效率过低;过多的PG 数量则会增加集群存储节点的计算资源负担。PG的数量在 Ceph的存储池Pool)创建时指定,通常推荐每个OSD守护进程承载 100PG较为合适,考虑到集群数据的副本策略,对于单存储池的简单场景,可以通过如下公式进行PG数量确定。

 

TotalPGs=(OSDs×100)/Replicas

在上述数据寻址计算中,可以看到要对Hash计算结果进行取模运算,存储池的 PG量建议取值为 2n次方,这样可以加速数据寻址的计算过程,即对上述公式计算结果,向上或向下靠近2n次方数值进行存储池的PG总数选取。

对于多存储池的复杂场景,可以参考 Ceph官方推荐的计算器。

 

2.3.2      PG的状态机

PG状态的迁移通过状态机来驱动,我们先看一下PG状态机的主要事件定义,见表2-2

2-2     PG状态机

 

Activating

Peering 已经完成,PG 正在等待所有 PG 实例同步并固化 Peering 的结果(Info、log

Active

活跃态。PG  可以正常处理来自客户端的读写请求

 

Backfilling

正在后台填充态。Backfill是 Recovery的一种特殊场景,指 peering 完成后,如果基于当前权威日志无法对 UpSet 当中的某些 PG 实例实施增量同步(例如承载这些 PG 实例的 OSD 离线太久, 或者是新的 OSD 加入集群导致的 PG 实例整体迁移), 则通过完全复制当前Primary所有对象的方式进行全量同步

Backfill-toofull

某个需要被 Backfill 的 PG实例,其所在的 OSD 可用空间不足,Backfill流程当前被挂起

Backfill-wait

等待 Backfill 资源预留

Clean

干净态。PG 当前不存在待修复的对象,Acting Set 和Up Set 内容一致,并且大小等于存储池的副本数

Creating

PG 正在被创建

Deep

PG 正在或者即将进行对象一致性扫描清洗

Degraded

降级状态,Peering 完成后,PG 检测到任意一个PG实例存在不一致需要被同步/修复的对象,或者当前Acting Set 小于存储池副本数

 

Down

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

Incomplete

Peering 过程中,由于 a. 无法选出权威日志;b. 通过 choose_acting 选出的 ActingSet 后续不足以完成数据修复,导致 Peering 无法正常完成

Inconsistent

不一致态,集群清理和深度清理后检测到PG 中的对象副本存在不一致,例如对象的文件大小不一致或Recovery结束后一个对象的副本丢失

Peered

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

Peering

正在同步态。PG 正在执行同步处理

Recovering

正在恢复态。集群正在执行迁移或同步对象和它们的副本

Recovering-wait

等待Recovery资源预留


续表

 

 

Remapped

重新映射态。PG  活动集任何的一个改变,数据发生从老活动集到新活动集的迁移。在迁移期间还是用老的活动集中的主OSD 处理客户端请求,一旦迁移完成,新活动集中的主 OSD开始处理

Repair

PG 在执行Scrub 过程中,如果发现存在不一致的对象,并且能够修复,则自动进入修复状态

Scrubbing

PG 正在或者即将进行对象一致性扫描

Inactive

非活跃态。PG不能处理读写请求

Unclean

非干净态。PG不能从上一个失败中恢复

Stale

未刷新态。PG状态没有被任何 OSD 更新,这说明所有存储这个PG 的 OSD 可能挂掉,或者Mon没有检测到 Primary统计信息(网络抖动)

Undersized

PG 当前的ActingSet 小于存储池副本数

 

需要注意的是,这些状态并不是互斥的,某些时刻PG可能处于多个状态的叠加中,例如 Active+ Clean 表示一切正常,Active+ Degraded+ Recovering表明 PG存在降级对象并且正在执行修复等。集群拓扑或者状态的变化,例如 OSD加入和删除、OSD宕掉或恢复、存储池创建和删除等,最终都会转化为状态机中的事件,这些事件会驱动状态机   在不同状态之间进行跳转。

以下几个状态在集群日常运行及运维中较为常见,简要介绍一下。

◆  Peering

Peering指的是 PG包含的冗余组中的所有对象达到一致性的过程,Peering时间的长短并不可控,主要是在于请求的OSD是否能够及时响应;如果这个阶段某个 OSD宕掉,很可能导致部分 PG一直处在 Peering 状态,即所有分布到这个 PG上的 I/O 都会阻塞。

◆  Degraded

降级状态,如在副本模式下(size参数配置为3,每个PG3个副本,分别保存在不同的 OSD守护进程中。在非故障情况下,这个PGActive+clean状态,一旦出现OSD守护进程离线PG的副本数就会小于3PG就转变为了 Degraded降级状态。

◆  Peered

Peering已经完成PG等待其他副本OSD守护进程上线状态,此状态下 PG不可对外提供服务。

结合上述 Degraded状态,PG当前存活副本数大于或等于存储池规定的最小副本数(min_size,通常设置为2,PGActive+Undersized+Degraded状态,仍可对外提供I/O服务;PG当前存活副本数小于存储池规定的最小副本数(min_size,PGUndersized+Degraded+Peered状态,不可对外提供 I/O服务。

◆  Remapped

Peering 已经完成,PG当前的 ActingSetUpSet 不一致就会出现 Remapped 状态,此状态下的 PG 正在进行数据的自我修复。该状态下,PG 可以进行正常的 I/O 读写。

上述讨论 Peered状态时,如果 PG内的另外两个 OSD 守护进程对应的存储介质损坏,将其移出存储集群后,Ceph会将PG 内的数据从仅存的OSD 上向集群内其他的OSD进行移(PG的重映射,丢失的数据是要从仅存的OSD上回填到新的OSD上的,处于回填状态的PG就会被标记为 Backfilling

◆  Recovery

Ceph基于 PG 级别的日志保证副本之间的数据一致性,Recovery指对应副本能够通过日志(PGLog1)进行恢复,即只需要修复该副本上与权威日志不同步的那部分对象,即可完成存储系统内数据的整体恢复。

Recovery 有两种恢复方式。

(1)  Pull:指 Primary自身存在降级的对象,由 Primary按照 missing_loc选择合适的副本去拉取降级对象的权威日志到本地,然后完成修复。

(2)  Push:指Primary 感知到一个或者多个副本当前存在降级对象,主动推送每个降级对象的权威版本至相应的副本,然后再由副本本地完成修复。

为了修复副本Primary必须先完成自我修复,即通常情况下,总是先执行Pull作,再执行 Push的操作但是如果客户端正好需要改写某个只在从副本上处于降级状态的对象,那么此时 PG会强制通过Push 的方式优先修复对象,以避免长时间阻塞客户端的相关请求。另一个必须这样处理的原因在于,客户端的请求,都是由 Primary一处理的, 为了及时响应客户端的请求, 也必须优先恢复 Primary的本地数据。完成自我修复后Primary可以着手修复各个副本中的降级对象。因为在此前的 Peering程中Primary已经为每个副本生成了完整的missing列表, 可以据此逐个副本完成修复。

客户端发起读请求,待访问的对象在一个或者多个副本上处于降级状态,对应的读请求可以直接在 Primary上完成,对象仅仅在副本上降级,无任何影响。如果 Primary上也处于降级状态,需要等 Primary完成修复,才能继续。

 

1记录的 PGLogosd_max_pg_log_entries=10000条以内,这个时候通过 PGLog就能增量恢复数


相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
18天前
|
运维 云计算 Docker
深入理解与实践:基于Docker的微服务架构优化策略
本文旨在为软件开发和运维人员提供一个全面的指南,探讨如何通过Docker容器技术优化微服务架构。我们不仅深入分析了Docker在微服务环境中的关键作用,还提出了一系列实践策略,以提高部署效率、增强系统稳定性,并确保服务的可伸缩性和安全性。通过具体案例分析和比较传统部署方式的局限性,本文展示了Docker如何成为微服务架构优化不可或缺的工具,旨在帮助读者构建一个更加灵活、高效和可靠的服务环境。
16 1
|
22天前
|
存储 算法 关系型数据库
Ceph介绍及原理架构分享
Ceph介绍及原理架构分享
118 0
|
23天前
|
设计模式 Java 应用服务中间件
Tomcat 架构原理解析到设计借鉴
Tomcat 架构原理解析到设计借鉴
116 0
|
23天前
|
设计模式 Java 应用服务中间件
Tomcat 架构原理解析到架构设计借鉴
Tomcat 架构原理解析到架构设计借鉴
71 0
|
23天前
|
消息中间件 存储 设计模式
Kafka原理篇:图解kakfa架构原理
Kafka原理篇:图解kakfa架构原理
21 1
|
5天前
|
存储 缓存 程序员
DP读书:鲲鹏处理器 架构与编程(三)高性能处理器的存储组织与片上互联
DP读书:鲲鹏处理器 架构与编程(三)高性能处理器的存储组织与片上互联
20 0
|
16天前
|
存储 自然语言处理 前端开发
软考实践之分层架构思想的理论和应用实践
软考实践之分层架构思想的理论和应用实践
36 0
|
19天前
|
敏捷开发 弹性计算 架构师
浅谈微服务架构下的数据库设计与实践
在当今快速发展的软件工程领域,微服务架构因其高度的模块化和灵活性而受到广泛欢迎。然而,随之而来的是对数据库设计和管理提出了新的挑战。本文将探讨在微服务架构下,如何有效地设计和实践数据库以支持服务的独立性、数据的一致性和系统的扩展性。我们将从微服务的数据库隔离策略谈起,深入分析数据库的分库分表、事务管理、数据一致性解决方案等关键技术,并通过实例说明如何在实际项目中应用这些原则和技术。本文旨在为软件开发者和架构师提供一份指南,帮助他们在微服务架构的环境下,更好地进行数据库设计和管理。
18 1
|
22天前
|
网络协议 中间件 数据库
Zookeeper学习系列【三】Zookeeper 集群架构、读写机制以及一致性原理(ZAB协议)
Zookeeper学习系列【三】Zookeeper 集群架构、读写机制以及一致性原理(ZAB协议)
62 0
|
22天前
|
存储 缓存 关系型数据库
Mysql专栏 - Linux底层交互和Raid存储架构
Mysql专栏 - Linux底层交互和Raid存储架构
66 0