带你读《存储漫谈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型的磁盘上。

相关文章
|
22天前
|
监控 Java 持续交付
后端开发中的微服务架构实践与挑战####
在当今快速迭代的软件开发领域,微服务架构以其灵活性和可扩展性成为众多企业的首选。本文探讨了微服务架构的核心概念、实施策略及面临的主要挑战,旨在为后端开发者提供一个全面的指南。通过分析真实案例,揭示微服务在提升系统敏捷性的同时,如何有效应对分布式系统的复杂性问题。 ####
|
12天前
|
运维 持续交付 云计算
深入解析云计算中的微服务架构:原理、优势与实践
深入解析云计算中的微服务架构:原理、优势与实践
40 1
|
22天前
|
消息中间件 存储 缓存
十万订单每秒热点数据架构优化实践深度解析
【11月更文挑战第20天】随着互联网技术的飞速发展,电子商务平台在高峰时段需要处理海量订单,这对系统的性能、稳定性和扩展性提出了极高的要求。尤其是在“双十一”、“618”等大型促销活动中,每秒需要处理数万甚至数十万笔订单,这对系统的热点数据处理能力构成了严峻挑战。本文将深入探讨如何优化架构以应对每秒十万订单级别的热点数据处理,从历史背景、功能点、业务场景、底层原理以及使用Java模拟示例等多个维度进行剖析。
49 8
|
6天前
|
消息中间件 运维 安全
后端开发中的微服务架构实践与挑战####
在数字化转型的浪潮中,微服务架构凭借其高度的灵活性和可扩展性,成为众多企业重构后端系统的首选方案。本文将深入探讨微服务的核心概念、设计原则、关键技术选型及在实际项目实施过程中面临的挑战与解决方案,旨在为开发者提供一套实用的微服务架构落地指南。我们将从理论框架出发,逐步深入至技术细节,最终通过案例分析,揭示如何在复杂业务场景下有效应用微服务,提升系统的整体性能与稳定性。 ####
22 1
|
7天前
|
消息中间件 运维 API
后端开发中的微服务架构实践####
本文深入探讨了微服务架构在后端开发中的应用,从其定义、优势到实际案例分析,全面解析了如何有效实施微服务以提升系统的可维护性、扩展性和灵活性。不同于传统摘要的概述性质,本摘要旨在激发读者对微服务架构深度探索的兴趣,通过提出问题而非直接给出答案的方式,引导读者深入
23 1
|
8天前
|
弹性计算 Kubernetes API
构建高效后端服务:微服务架构的深度剖析与实践####
本文深入探讨了微服务架构的核心理念、设计原则及实现策略,旨在为开发者提供一套系统化的方法论,助力其构建灵活、可扩展且易于维护的后端服务体系。通过案例分析与实战经验分享,揭示了微服务在提升开发效率、优化资源利用及增强系统稳定性方面的关键作用。文章首先概述了微服务架构的基本概念,随后详细阐述了其在后端开发中的应用优势与面临的挑战,最后结合具体实例,展示了如何从零开始规划并实施一个基于微服务的后端项目。 ####
|
14天前
|
消息中间件 运维 开发者
后端开发中的微服务架构实践与挑战####
本文深入探讨了微服务架构在后端开发中的应用,从其核心概念、设计原则到实际部署过程中面临的挑战进行了全面剖析。不同于传统的单体应用,微服务通过将复杂系统拆解为一系列小型、独立的服务,提高了系统的灵活性和可维护性。然而,这种架构的转变也伴随着服务间通信、数据一致性、部署复杂性等新问题。本文旨在为开发者提供一套应对这些挑战的策略,同时分享一些成功案例,以期促进微服务架构的有效实施。 ####
|
16天前
|
缓存 负载均衡 API
后端开发中的微服务架构实践与挑战####
在数字化转型的浪潮中,微服务架构凭借其高度的可扩展性、灵活性及易于维护的特点,成为众多企业后端开发的首选架构模式。本文将深入探讨微服务架构的核心理念,通过具体案例分析其在实际应用中的实践策略与面临的挑战,为读者提供一份详尽的微服务架构实施指南。 ####
|
18天前
|
消息中间件 负载均衡 测试技术
后端开发中的微服务架构实践与挑战####
本文旨在探讨微服务架构在后端开发中的应用实践,深入分析其带来的优势与面临的挑战。通过剖析真实案例,揭示微服务转型过程中的关键技术决策、服务拆分策略、以及如何有效应对分布式系统的复杂性问题。文章还将提供一套评估企业是否适合采用微服务架构的框架,帮助读者更好地理解这一架构模式,并为企业的技术选型提供参考。 ####
|
16天前
|
运维 监控 安全
深入理解微服务架构:设计原则、挑战与实践
深入理解微服务架构:设计原则、挑战与实践