带你读《存储漫谈Ceph原理与实践》第二章Ceph 架构2.2 Ceph 数据寻址(二)

简介: 带你读《存储漫谈Ceph原理与实践》第二章Ceph 架构2.2 Ceph 数据寻址

2.2.2   CRUSH算法因子


上述介绍可以看出,CRUSH算法在 Ceph存储系统的数据寻址中占有核心地位,Ceph存储系统通过 CRUSH 算法规则来控制数据的分布策略,Ceph存储系统的 CRUSH算法能够控制对象文件在存储集群中随机均匀地分布。

CRUSH算法包含两个关键输入因子:层次化的 ClusterMap以及数据分布策略PlacementRules。

1.  层次化的 ClusterMap

 

层次化的 ClusterMap 反映了存储系统层级的物理拓扑结构。

Ceph存储集群通过 ClusterMap定义了 OSD守护进程的静态拓扑关系层级信,使得CRUSH算法在选择OSD时具备了主机、机架、机房等信息的感知能力。通过 ClusterMap规则定义,Ceph 存储系统允许数据副本可以分布在不同的主机、不同的机架,甚至不同的机房中,提高了数据存储的安全性。

ClusterMap由设备(device)和桶(bucket)组成,device是最基本的存储设备,也就是 OSD,通常 1OSD对应 1 个磁盘存储设备,bucket 表示存放设备的容器,可以包含多个设备或子类型的 bucket。

存储设备(device)的权重由管理员设置,以控制设备负责存储的相对数据量,device的权重值越高,对应的磁盘就会被分配写入更多的数据。大型存储系统中的存储设备(磁盘)通常存在容量大小不等或者性能高低不一的情况,系统管理员可以依据存储设备的利用率   和负载来设定权重,随机数据分布算法,以此控制数据的最终分布,实现存储系统设备的   数据量均衡,进而平衡存储系统的I/O 负载,最终提高存储集群整体的性能和可靠性。

桶的权重是它所包含的所有元素(devicebucket)权重的总和。Bucket可以包含很多种类型,例如,Host 就代表一个主机节点,可以包含多个 deviceRack 代表机架,包含多个 host节点。Ceph中默认有 OSD、host、Chassis、Rack、row、PDU、Pod、Room、Datacenter、Region、root共计11个层级(同时也允许用户定义自己新的类型,它们含义如下。

OSD                                                   磁盘设备,对应 OSD守护进程

host                                                    包含若干个 OSD的主机

Chassis                                              包含若干个刀片服务器的机箱

Rack                                                   包含若干个主机的机架

row                                                     包含若干个主机的一排机柜

PDU                                                    为机柜分配的电源插排

Pod                                                     一个数据中心中的机房单间

Room                                                  含若干个机柜和主机的机房

Datacenter                                         包含若干机房的数据中心

Region                                                包含若干数据中心的区域

root                                                     bucket分层结构的根

通常 OSD、host、Rack 层级较为常用。下面举例说明 bucket的用法。

 

 

host test1{

 

// 类型host,名字为 test1

id -2

 

//bucket的 ID,⼀般为负值

#weight 3.000

 

// 权重,默认为⼦ item 的权重之和

algstraw

 

//bucket随机选择的算法

hash 0

 

//bucket随机选择的算法使⽤的 hash函数

 

 

// 这⾥ 0代表使⽤ hash 函数 jenkins1

itemosd.1 weight

1.000

//item1: osd.1 和权重

itemosd.2 weight

1.000

 

itemosd.3 weight

}

1.000

 

 

host test2{id -3

# weight 3.00algstrawhash 0

item osd.3 weight 1.000item osd.4 weight 1.000itemosd.5 weight 1.000

}

 

rootdefault{                     //root的类型为bucket,名字为 defaultid -1                            //ID

# weight 6.000algstraw

hash 0

item test1 weight 3.000itemtest2 weight 3.000


}

 

 

根据上面 ClusterMap的语法定义,图 2-2 给出了比较直观的层级化的树形结构。

如图2-2所示,CephClusterMap是一个由 bucketdevice 共同组成的树形存储层次结构,叶子节点是device也就是OSD,其他的节点称为bucket节点,这些bucket都是逻辑上的概念,是对物理结构的抽象如对数据中心的抽象、机房的抽象、机架的抽象、主机的抽象等,树形结构只有一个最终的根节点,称为root点,root也是一个抽象的逻辑概念。

image.png


2-2CephCusterMap层级结构

 

在上面的 ClusterMap中,有一个 root类型的 bucket,名字为 defaultroot下面有两个 host类型的bucket,名字分别为 test1test2,其下分别各有3OSD设备,每device的权重都为 1.000,说明它们的容量大小都相同。host 的权重为子设备之和,即test1test2 的权重均为3.000,它是自动计算的,不需要设置;同理,root 的权重为6.000

2.  数据分布策略 PlacementRules

 

PlacementRules决定了一个 PG的对象(副本或纠删码策略)如何选择 OSD,通过这些自定义的规则,用户可以设置副本在集群中的分布。Ceph 存储系统的PlacementRules 定义格式如下。

 

take(a)choose

choose firstn {num} type {bucket-type}chooseleaffirstn{num} type{bucket-type}

If{num}== 0choose pool-num-replicasbuckets (all-available).

If {num} > 0 && <pool-num-replicaschoose that many buckets.

If {num} < 0it means pool-num-replicas- |{num}|.

Emit

 

PlacementRules 的执行流程如下。

(1) take操作选择一个 bucket,一般是root类型的 bucket。

(2)  choose 操作有不同的选择方式,其输入都是上一步的输出。

a)choosefirstn 深度优先选择出 num个类型为 bucket-type的子 bucket。b)chooseleaf先选择出 num个类型为bucket-type的子 bucket,然后递归到叶子节

点,选择一个OSD 设备。

i.  如果 num0,num就为 Pool 设置的副本数;

ii.  如果 num大于 0,小于Pool 的副本数,那么就选出 num个;

iii.   如果 num小于 0,就选出 Pool 的副本数减去 num 的绝对值。

(3) emit输出结果。

由上述流程可以看出,PlacementRules主要定义以下 3个关键操作。

1CRUSHMap中的哪个节点开始查找;

2)使用哪个节点作为故障隔离域;

3)定位副本的搜索模式(广度优先或深度优先

 

3.  示例

 

(1)3 个副本分布在 1row 下的 3cabinet 中。

在图2-3中,最下面的长方形图例代表一台主机,里面的圆柱形图例代表OSDcabinet图例代表一个机柜,row图例代表一排机柜,顶端的 root是根节点,可以把它理解成一个数据中心。


 image.png

2-3  Ceph数据分布示意(CusterMap)

 

自顶而下来看,顶层是一个 rootbucket,每个 root下有 4row类型 bucket,每row下面有 4cabinet,每个cabinet下有若干个 OSD设备图中有 4host,每个host有若干个 OSD设备,但是在本 CRUSHMap中并没有设置host这一级别的 bucket,而是直接把4host上的所有OSD设备定义为一个cabinet

该场景下,PlacementRules定义如下。

rulereplicated_ruleset {

ruleset 0                            //ruleset的编号ID

typereplicated                      //类型 replicated或者erasurecode

min_size 1                           //副本数最⼩值

max_size 10                          //副本数最⼤值

 

step take root                       //选择⼀个rootbucket,做下⼀步的输⼊

step choose firstn 1type row         //选择⼀个 row,同⼀排

stepchoosefirstn3typecabinet     //选择3cabinet3副本分别在不同的cabinet

stepchoosefirstn1typeosd         //在上⼀步输出的3cabinet中,分别选择⼀个OSD

stepemit

}

 

 

 

根据上面的 ClusterMapPlacementRules 定义,选择算法的执行过程如下。1)选中 rootbucket作为下一个步骤的输入;

2) root类型的 bucket中选择 1row类的子 bucket,其选择的算法在 root的定义中设置,一般设置为 straw算法;

3)从上一步的输出row中,选择 3cabinet,其选择的算法在 row中定义;4)从上一步输出的3cabinet中,分别选出一个 OSD,并输出。

最终实现效果为可选择出3OSD 设备,分布在1row上的 3cabinet中。

(2)  主副本分布在 SSD 上,其他副本分布在 HDD上。

如图 2-4所示的 ClusterMap定义了 2root类型的 bucket,一个是名为SSDroot类型的 bucket,其 OSD存储介质都是SSD固态硬盘,它包含 2host,每个host上的存储设备都是 SSD固态硬盘;另一个是名为 HDDroot类型的bucket,其 OSD储介质都是 HDD硬盘,它有 2host,每个host上的设备都是 HDD硬盘。

image.png

 

 

 image.png

 

2-4Ceph数据分布示意(CusterMap)

 

该场景下,PlacementRules定义如下。

rule ssd-primary {

ruleset 0

type replicatedmin_size 1

max_size10

 

step take ssd                        //选择SSD这个rootbucket为输⼊step chooseleaf firstn 1 type host         //选择⼀个host,并递归选择叶⼦节点 OSDstep emit                            //输出结果

 

step take hdd                        //选择HDD这个rootbucket为输⼊

step chooseleaf firstn -1 type host   //选择总副本数减⼀个host

//并分别递归选择⼀个叶⼦节点OSD

step emit                            //输出结果


}

 

根据上面的 ClusterMapPlacementRules 定义,选择算法的执行过程如下。1)首先 take操作选择 ssdroot类型的 bucket

2) SSDroot中先选择一个 host,然后以该 host 为输入,递归至叶子节点,选择一个 OSD设备;

3)输出选择的设备,也就是SSD设备;

4)选择 HDD作为 root的输入;

5) 选择2host副本数减1,默认3副本,并分别递归选择一个OSD设备,最终选出 2HDD设备;

6)输出最终结果。

最终实现效果为输出 3个设备,一个是 SSD类型的磁盘,另外两个是 HDD磁盘。通过上述规则,就可以把PG的主副本存储在SSD类型的 OSD上,其他副本分布在HDD型的磁盘上。

相关文章
|
4月前
|
数据采集 监控 API
移动端性能监控探索:iOS RUM SDK 技术架构与实践
阿里云 RUM SDK 作为一款性能体验监控采集工具,可以作为辅助 App 运维的强有力助手,提升您的问题排查效率。
344 53
|
4月前
|
存储 运维 分布式计算
零售数据湖的进化之路:滔搏从Lambda架构到阿里云Flink+Paimon统一架构的实战实践
在数字化浪潮席卷全球的今天,传统零售企业面临着前所未有的技术挑战和转型压力。本文整理自 Flink Forward Asia 2025 城市巡回上海站,滔搏技术负责人分享了滔搏从传统 Lambda 架构向阿里云实时计算 Flink 版+Paimon 统一架构转型的完整实战历程。这不仅是一次技术架构的重大升级,更是中国零售企业拥抱实时数据湖仓一体化的典型案例。
310 0
|
5月前
|
数据采集 运维 数据可视化
AR 运维系统与 MES、EMA、IoT 系统的融合架构与实践
AR运维系统融合IoT、EMA、MES数据,构建“感知-分析-决策-执行”闭环。通过AR终端实现设备数据可视化,实时呈现温度、工单等信息,提升运维效率与生产可靠性。(238字)
|
5月前
|
数据采集 存储 运维
MyEMS:技术架构深度剖析与用户实践支持体系
MyEMS 是一款开源能源管理系统,采用分层架构设计,涵盖数据采集、传输、处理与应用全流程,支持多协议设备接入与多样化能源场景。系统具备高扩展性与易用性,结合完善的文档、社区、培训与定制服务,助力不同技术背景用户高效实现能源数字化管理,降低使用门槛与运维成本,广泛适用于工业、商业及公共机构等场景。
230 0
|
4月前
|
存储 SQL 消息中间件
从 ClickHouse 到 StarRocks 存算分离: 携程 UBT 架构升级实践
查询性能实现从秒级到毫秒级的跨越式提升
|
6月前
|
数据采集 缓存 前端开发
如何开发门店业绩上报管理系统中的商品数据板块?(附架构图+流程图+代码参考)
本文深入讲解门店业绩上报系统中商品数据板块的设计与实现,涵盖商品类别、信息、档案等内容,详细阐述技术架构、业务流程、数据库设计及开发技巧,并提供完整代码示例,助力企业构建稳定、可扩展的商品数据系统。
|
5月前
|
数据采集 机器学习/深度学习 搜索推荐
MIT新论文:数据即上限,扩散模型的关键能力来自图像统计规律,而非复杂架构
MIT与丰田研究院研究发现,扩散模型的“局部性”并非源于网络架构的精巧设计,而是自然图像统计规律的产物。通过线性模型仅学习像素相关性,即可复现U-Net般的局部敏感模式,揭示数据本身蕴含生成“魔法”。
260 3
MIT新论文:数据即上限,扩散模型的关键能力来自图像统计规律,而非复杂架构
|
4月前
|
存储 NoSQL 前端开发
【赵渝强老师】MongoDB的分布式存储架构
MongoDB分片通过将数据分布到多台服务器,实现海量数据的高效存储与读写。其架构包含路由、配置服务器和分片服务器,支持水平扩展,结合复制集保障高可用性,适用于大规模生产环境。
398 1
|
5月前
|
JSON 供应链 监控
1688商品详情API技术深度解析:从接口架构到数据融合实战
1688商品详情API(item_get接口)可通过商品ID获取标题、价格、库存、SKU等核心数据,适用于价格监控、供应链管理等场景。支持JSON格式返回,需企业认证。Python示例展示如何调用接口获取商品信息。

热门文章

最新文章