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

相关文章
|
6天前
|
监控 Java 持续交付
后端开发中的微服务架构实践与挑战####
在当今快速迭代的软件开发领域,微服务架构以其灵活性和可扩展性成为众多企业的首选。本文探讨了微服务架构的核心概念、实施策略及面临的主要挑战,旨在为后端开发者提供一个全面的指南。通过分析真实案例,揭示微服务在提升系统敏捷性的同时,如何有效应对分布式系统的复杂性问题。 ####
|
6天前
|
消息中间件 存储 缓存
十万订单每秒热点数据架构优化实践深度解析
【11月更文挑战第20天】随着互联网技术的飞速发展,电子商务平台在高峰时段需要处理海量订单,这对系统的性能、稳定性和扩展性提出了极高的要求。尤其是在“双十一”、“618”等大型促销活动中,每秒需要处理数万甚至数十万笔订单,这对系统的热点数据处理能力构成了严峻挑战。本文将深入探讨如何优化架构以应对每秒十万订单级别的热点数据处理,从历史背景、功能点、业务场景、底层原理以及使用Java模拟示例等多个维度进行剖析。
27 8
|
8天前
|
存储 分布式计算 数据挖掘
数据架构 ODPS 是什么?
数据架构 ODPS 是什么?
64 7
|
8天前
|
数据采集 搜索推荐 数据管理
数据架构 CDP 是什么?
数据架构 CDP 是什么?
31 2
|
7天前
|
SQL Java 数据库连接
Mybatis架构原理和机制,图文详解版,超详细!
MyBatis 是 Java 生态中非常著名的一款 ORM 框架,在一线互联网大厂中应用广泛,Mybatis已经成为了一个必会框架。本文详细解析了MyBatis的架构原理与机制,帮助读者全面提升对MyBatis的理解和应用能力。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
Mybatis架构原理和机制,图文详解版,超详细!
|
2天前
|
消息中间件 负载均衡 测试技术
后端开发中的微服务架构实践与挑战####
本文旨在探讨微服务架构在后端开发中的应用实践,深入分析其带来的优势与面临的挑战。通过剖析真实案例,揭示微服务转型过程中的关键技术决策、服务拆分策略、以及如何有效应对分布式系统的复杂性问题。文章还将提供一套评估企业是否适合采用微服务架构的框架,帮助读者更好地理解这一架构模式,并为企业的技术选型提供参考。 ####
|
5天前
|
Cloud Native Devops 持续交付
云原生架构的演进与实践
本文深入探讨了云原生架构的核心概念、技术组件及其在现代软件开发中的应用。通过分析容器化、微服务、持续集成/持续部署(CI/CD)等关键技术,揭示了这些技术如何共同促进应用程序的灵活性、可扩展性和高可用性。文章还讨论了云原生架构实施过程中面临的挑战和最佳实践,旨在为开发者和企业提供一套实用的指导方针,以便更有效地利用云计算资源,加速数字化转型的步伐。
20 5
|
7天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
31 5
|
11天前
|
监控 Go API
Go语言在微服务架构中的应用实践
在微服务架构的浪潮中,Go语言以其简洁、高效和并发处理能力脱颖而出,成为构建微服务的理想选择。本文将探讨Go语言在微服务架构中的应用实践,包括Go语言的特性如何适应微服务架构的需求,以及在实际开发中如何利用Go语言的特性来提高服务的性能和可维护性。我们将通过一个具体的案例分析,展示Go语言在微服务开发中的优势,并讨论在实际应用中可能遇到的挑战和解决方案。
|
9天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型浪潮中,企业纷纷拥抱云计算,而云原生架构作为其核心技术支撑,正引领着一场深刻的技术变革。本文聚焦于云原生环境下微服务架构的治理策略与实践,探讨如何通过精细化的服务管理、动态的流量调度、高效的故障恢复机制以及持续的监控优化,构建弹性、可靠且易于维护的分布式系统。我们将深入剖析微服务治理的核心要素,结合具体案例,揭示其在提升系统稳定性、扩展性和敏捷性方面的关键作用,为读者提供一套切实可行的云原生微服务治理指南。 ####
下一篇
无影云桌面