Ceph分布式存储实战3.2 CRUSH基本原理

简介:

3.2 CRUSH基本原理


众所周知,存储设备具有吞吐量限制,它影响读写性能和可扩展性能。所以,存储系统通常都支持条带化以增加存储系统的吞吐量并提升性能,数据条带化最常见的方式是做RAID。与Ceph的条带化最相似的是RAID 0或者是“带区卷”。Ceph条带化提供了类似于RAID 0的吞吐量,N路RAID镜像的可靠性以及更快速的恢复能力。

在磁盘阵列中,数据是以条带(stripe)的方式贯穿在磁盘阵列所有硬盘中的。这种数据的分配方式可以弥补OS读取数据量跟不上的不足。

1)将条带单元(stripe unit)从阵列的第一个硬盘到最后一个硬盘收集起来,就可以称为条带(stripe)。有的时候,条带单元也被称为交错深度。在光纤技术中,一个条带单元被叫作段。

2)数据在阵列中的硬盘上是以条带的形式分布的,条带化是指数据在阵列中所有硬盘中的存储过程。文件中的数据被分割成小块的数据段在阵列中的硬盘上顺序的存储,这个最小数据块就叫作条带单元。

决定Ceph条带化数据的3个因素。

对象大小:处于分布式集群中的对象拥有一个最大可配置的尺寸(例如,2MB、4MB等),对象大小应该足够大以适应大量的条带单元。

条带宽度:条带有一个可以配置的单元大小,Ceph Client端将数据写入对象分成相同大小的条带单元,除了最后一个条带之外;每个条带宽度,应该是对象大小的一小部分,这样使得一个对象可以包含多个条带单元。

条带总量:Ceph客户端写入一系列的条带单元到一系列的对象,这就决定了条带的总量,这些对象被称为对象集,当Ceph客户端端写入的对象集合中的最后一个对象之后,它将会返回到对象集合中的第一个对象处。

3.2.1 Object与PG

Ceph条带化之后,将获得N个带有唯一oid(即object的id)。Object id是进行线性映射生成的,即由file的元数据、Ceph条带化产生的Object的序号连缀而成。此时Object需要映射到PG中,该映射包括两部分。

1)由Ceph集群指定的静态Hash函数计算Object的oid,获取到其Hash值。

2)将该Hash值与mask进行与操作,从而获得PG ID。

根据RADOS的设计,假定集群中设定的PG总数为M(M一般为2的整数幂),则mask的值为M–1。由此,Hash值计算之后,进行按位与操作是想从所有PG中近似均匀地随机选择。基于该原理以及概率论的相关原理,当用于数量庞大的Object以及PG时,获得到的PG ID是近似均匀的。

计算PG的ID示例如下。

1)Client输入pool ID和对象ID(如pool=‘liverpool’,object-id=‘john’)。

2)CRUSH获得对象ID并对其Hash运算。

3)CRUSH计算OSD个数,Hash取模获得PG的ID(如0x58)。

4)CRUSH获得已命名pool的ID(如liverpool=4)。

5)CRUSH预先考虑到pool ID相同的PG ID(如4.0x58)。

3.2.2 PG与OSD

由PG映射到数据存储的实际单元OSD中,该映射是由CRUSH算法来确定的,将PG ID作为该算法的输入,获得到包含N个OSD的集合,集合中第一个OSD被作为主OSD,其他的OSD则依次作为从OSD。N为该PG所在POOL下的副本数目,在生产环境中N一般为3;OSD集合中的OSD将共同存储和维护该PG下的Object。需要注意的是,CRUSH算法的结果不是绝对不变的,而是受到其他因素的影响。其影响因素主要有以下两个。

一是当前系统状态。也就是上文逻辑结构中曾经提及的Cluster Map(集群映射)。当系统中的OSD状态、数量发生变化时,Cluster Map可能发生变化,而这种变化将会影响到PG与OSD之间的映射。

二是存储策略配置。这里的策略主要与安全相关。利用策略配置,系统管理员可以指定承载同一个PG的3个OSD分别位于数据中心的不同服务器乃至机架上,从而进一步改善存储的可靠性。

因此,只有在Cluster Map和存储策略都不发生变化的时候,PG和OSD之间的映射关系才是固定不变的。在实际使用中,策略一经配置通常不会改变。而系统状态的改变或者是因为设备损坏,或者是因为存储集群规模扩大。好在Ceph本身提供了对于这种变化的自动化支持,因而,即便PG与OSD之间的映射关系发生了变化,并不会对应用造成困扰。事实上,Ceph正是需要有目的的利用这种动态映射关系。正是利用了CRUSH的动态特性,Ceph才可以将一个PG根据需要动态迁移到不同的OSD组合上,从而自动化地实现高可靠性、数据分布re-blancing等特性。

之所以在此次映射中使用CRUSH算法,而不是其他Hash算法,原因之一是CRUSH具有上述可配置特性,可以根据管理员的配置参数决定OSD的物理位置映射策略;另一方面是因为CRUSH具有特殊的“稳定性”,也就是当系统中加入新的OSD导致系统规模增大时,大部分PG与OSD之间的映射关系不会发生改变,只有少部分PG的映射关系会发生变化并引发数据迁移。这种可配置性和稳定性都不是普通Hash算法所能提供的。因此,CRUSH算法的设计也是Ceph的核心内容之一。

3.2.3 PG与Pool

Ceph存储系统支持“池”(Pool)的概念,这是存储对象的逻辑分区。

Ceph Client端从Ceph mon端检索Cluster Map,写入对象到Pool。Pool的副本数目,Crush规则和PG数目决定了Ceph将数据存储的位置,如图3-1所示。

Pool至少需要设定以下参数。

对象的所有权/访问权。

PG数目。

该pool使用的crush规则。

对象副本的数目。

Object、PG、Pool、OSD关系图,如图3-2所示。

 

图3-2 映射关系图

Pool相关的操作如下。

1)创建pool。

ceph osd pool create {pool-name} {pg-num} [{pgp-num}] [replicated] \

     [crush-ruleset-name] [expected-num-objects]

ceph osd pool create {pool-name} {pg-num}  {pgp-num}   erasure \

     [erasure-code-profile] [crush-ruleset-name] [expected_num_objects]

2)配置pool配额。

ceph osd pool set-quota {pool-name} [max_objects {obj-count}] [max_bytes {bytes}]

3)删除pool。

ceph osd pool delete {pool-name} [{pool-name} --yes-i-really-really-mean-it]

4)重命名pool。

ceph osd pool rename {current-pool-name} {new-pool-name}

5)展示pool统计。

rados df

6)给pool做快照。

ceph osd pool mksnap {pool-name} {snap-name}

7)删除pool快照。

ceph osd pool rmsnap {pool-name} {snap-name}

8)配置pool的相关参数。

ceph osd pool set {pool-name} {key} {value}

9)获取pool参数的值。

ceph osd pool get {pool-name} {key}

10)配置对象副本数目。

ceph osd pool set {poolname} size {num-replicas}

11)获取对对象副本数目。

ceph osd dump | grep 'replicated size'

相关文章
|
消息中间件 运维 Kafka
直播预告|Kafka+Flink双引擎实战:手把手带你搭建分布式实时分析平台!
在数字化转型中,企业亟需从海量数据中快速提取价值并转化为业务增长动力。5月15日19:00-21:00,阿里云三位技术专家将讲解Kafka与Flink的强强联合方案,帮助企业零门槛构建分布式实时分析平台。此组合广泛应用于实时风控、用户行为追踪等场景,具备高吞吐、弹性扩缩容及亚秒级响应优势。直播适合初学者、开发者和数据工程师,参与还有机会领取定制好礼!扫描海报二维码或点击链接预约直播:[https://developer.aliyun.com/live/255088](https://developer.aliyun.com/live/255088)
860 35
直播预告|Kafka+Flink双引擎实战:手把手带你搭建分布式实时分析平台!
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
326 2
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
消息中间件 运维 Kafka
直播预告|Kafka+Flink 双引擎实战:手把手带你搭建分布式实时分析平台!
直播预告|Kafka+Flink 双引擎实战:手把手带你搭建分布式实时分析平台!
451 11
|
数据采集 缓存 NoSQL
分布式新闻数据采集系统的同步效率优化实战
本文介绍了一个针对高频新闻站点的分布式爬虫系统优化方案。通过引入异步任务机制、本地缓存池、Redis pipeline 批量写入及身份池策略,系统采集效率提升近两倍,数据同步延迟显著降低,实现了分钟级热点追踪能力,为实时舆情监控与分析提供了高效、稳定的数据支持。
638 1
分布式新闻数据采集系统的同步效率优化实战
|
缓存 NoSQL 算法
高并发秒杀系统实战(Redis+Lua分布式锁防超卖与库存扣减优化)
秒杀系统面临瞬时高并发、资源竞争和数据一致性挑战。传统方案如数据库锁或应用层锁存在性能瓶颈或分布式问题,而基于Redis的分布式锁与Lua脚本原子操作成为高效解决方案。通过Redis的`SETNX`实现分布式锁,结合Lua脚本完成库存扣减,确保操作原子性并大幅提升性能(QPS从120提升至8,200)。此外,分段库存策略、多级限流及服务降级机制进一步优化系统稳定性。最佳实践包括分层防控、黄金扣减法则与容灾设计,强调根据业务特性灵活组合技术手段以应对高并发场景。
3965 7
|
监控 Java 调度
SpringBoot中@Scheduled和Quartz的区别是什么?分布式定时任务框架选型实战
本文对比分析了SpringBoot中的`@Scheduled`与Quartz定时任务框架。`@Scheduled`轻量易用,适合单机简单场景,但存在多实例重复执行、无持久化等缺陷;Quartz功能强大,支持分布式调度、任务持久化、动态调整和失败重试,适用于复杂企业级需求。文章通过特性对比、代码示例及常见问题解答,帮助开发者理解两者差异,合理选择方案。记住口诀:单机简单用注解,多节点上Quartz;若是任务要可靠,持久化配置不能少。
1317 4
|
存储 缓存 NoSQL
【📕分布式锁通关指南 12】源码剖析redisson如何利用Redis数据结构实现Semaphore和CountDownLatch
本文解析 Redisson 如何通过 Redis 实现分布式信号量(RSemaphore)与倒数闩(RCountDownLatch),利用 Lua 脚本与原子操作保障分布式环境下的同步控制,帮助开发者更好地理解其原理与应用。
965 6
|
存储 负载均衡 NoSQL
【赵渝强老师】Redis Cluster分布式集群
Redis Cluster是Redis的分布式存储解决方案,通过哈希槽(slot)实现数据分片,支持水平扩展,具备高可用性和负载均衡能力,适用于大规模数据场景。
903 2
|
存储 缓存 NoSQL
Redis核心数据结构与分布式锁实现详解
Redis 是高性能键值数据库,支持多种数据结构,如字符串、列表、集合、哈希、有序集合等,广泛用于缓存、消息队列和实时数据处理。本文详解其核心数据结构及分布式锁实现,帮助开发者提升系统性能与并发控制能力。

热门文章

最新文章