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

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

2.2.3    Bucket随机选择算法

Ceph 的设计目标是采用通用的硬件来构建大规模、高可用性、高扩展性、高性能的分布式存储系统。Ceph 的设计目标是可以管理大型分级存储网络的分布式存储系统,在网络中不同层级具有不同的故障容忍程度,这种容忍度称为故障域。

在通常情况下一台存储服务器会包含多个磁盘,每个机架则会有多台服务器,为了实现在这些服务器上构建的存储集群具有较高的可靠性,数据通常采用多副本策略,其副本存放分布在不同机架的服务器磁盘上。SageCeph存储系统中设计了CRUSH算法,它是一种基于深度优先的遍历算法,在CRUSH最初的实现中,Sage一共设计了4种不同的基本选择算法,这些算法也是后期算法的基础。

1.  几种类型的 bucket介绍

 

CRUSH中定义了 4种类型的bucket来代表集群架构中的叶子节点:一般类型 bucket

(uniformbucket、列表类型bucketlistbucket、树结构类型bucket(treebucket以及稻草类型bucket(strawbucket,这4种类型的bucket对应了4CRUSH算法。

◆  Uniformbucket

Uniform类型的 bucket在选择子节点时不考虑权重,全部随机选择,因此,它要求桶内所有元素的权值相等。它的查找速度最快,但桶内元素改变时,设备中的数据会被完全重组,uniformbucket适用于 bucket 中很少添加或删除元素,即存储系统 ClusterMap相对稳定的场景。

◆  Listbucket

List类型的 bucket 采用链表数据结构,链表中的元素可拥有任意的权重配置,在查找节点元素时,只能顺序进行,性能较差,时间复杂度为 O(n),这一特性限制了存储集群的 部署规模。但桶内新增元素时,listbucket 可以产生最优的数据移动,而桶内删除数据时,listbucket会增加额外的数据移动,即该类型bucket 更适用于小规模存储集群,且集群规模偶有扩展的场景。

◆  Treebucket

Tree类型的 bucket 采用加权二叉排序树数据结构,相较于链表数据结构,其节点元素查找效率更高,时间复杂度为 O(logn),适用于规模更大的存储集群管理。但当集群的ClusterMap发生变化时,树状结构需要旋转调整以作适配,这决定了该类型bucket更适合于规模较大、查找频繁,但集群结构相对稳定的场景。

◆  Strawbucket

Straw类型的 bucket 通过类似抽签的方式公平竞争来选取节点元素。定位副本时,bucket中的每一项元素都对应一个随机长度的straw数值,拥有最长长度最大straw数值的元素被选中。Straw类型bucket的定位过程比 listbuckettreebucket都要慢,但当集群结构出现变动(添加或删除元素)时,存储集群的数据移动量最优,即该类型bucket

更适用于集群规模常有变化的场景。

简要总结,当 bucket固定且集群设备规格统一时比如 Ceph存储系统搭建在完全相同磁盘配置的服务器集群上uniformbucket查找速度最快;如果一个bucket预计将会不断增长,则 listbucket在其列表开头插入新项时将提供最优的数据移动;而当删除bucketdevice 时,listbucket 带来额外的数据移动,strawbucket 则可以为子树之间的数据移动提供最优的解决方案。treebucket是一种适用于任何情况的 bucket,兼具性能与数据迁移效率,但其综合表现略低于 strawbucket。

Bucket   类型的选择需要基于预期的集群结构变化,权衡映射方法的元素查找运算量和储集群数据移动之间的效率,基于此观点,对比以上4种类型bucket如表2-1所示straw类型的 bucket综合表现最优。

表2-1    4种类型的bucket对比

 

类型

时间复杂度

添加元素难度

删除元素难度

uniform

O(1 )

poor

poor

list

O(n )

optimal

poor

tree

O(logn )

good

good

straw

O(n )

better

better

考虑到呈爆炸式增长的数据存储空间需求(CRUSH添加元素,在大型分布式存储系统中某些部件故障是常态(CRUSH删除元素,以及愈发严苛的数据可靠性需求需要将数据副本存储在更高级别的故障域中,如不同的数据中心,因此,CRUSH默认采用了性能较为均衡的straw 算法,strawbucket 也是Ceph 中默认的bucket 类型。

2.  Straw算法介绍

 

上文介绍到 straw类型的 bucket 通过类似抽签的方式公平竞争来选取节点元素,这种抽签算法即为 straw算法,它的关键在于如何计算签长。

核心计算过程如下。

staticintbucket_straw_choose(structcrush_bucket_straw*bucketintxintr)

{

    u32 i;

int high = 0;

    u64 high_draw = 0;

 

 

   u64draw;

for (i =0; i <bucket->h.size; i++) {

draw=crush_hash32_3(bucket->h.hashxbucket->h.items[i]r);draw &=0xffff;

draw*=bucket->straws[i];

if (i== 0|| draw> high_draw){high = i;

high_draw= draw;

}

}

returnbucket->h.items[high];

}


 

算法核心流程如下。

(1)  给出一个 PG_ID,作为 CRUSH_HASH方法的输入;

(2)  CRUSH_HASH(PG_ID,OSD_ID,r)方法调用之后,得出一个随机数;

(3)  对于所有的 OSD用它们的权重乘以每个OSD_ID 对应的随机数,得到乘积;

(4)  选出乘积最大的 OSD

(5) 这个 PG就会保存到这个 OSD上。

如果两次选出的 OSD一样,Ceph会递增 r再选一次,直到选出 3个编号不一样的OSD为止。

通过概率分布可知,只要样本容量足够大,那么最后选出的元素概率就会是相同的,   从而使数据可以得到均匀分布。但是在实际使用过程中,很多因素都会使得集群不够均衡,如磁盘容量不尽相同等,这就需要额外添加其他因子来控制差异。straw      算法就是通过使用权重对签长的计算过程进行调整来实现的,即让权重大的元素有较大的概率获取更大的   签长,从而更容易被抽中。

Straw算法选出一个元素的计算过程,其时间复杂度是O(n)

3.  Straw2算法介绍

 

理论上,在样本足够多的情况下,OSD 被选中的概率只与权重相关,下面以添加元素为例。

(1)  假定当前集合中一共有n个元素e1e2en

(2)  向集合中添加一个新元素en+1:(e1,e2,…,en,en+1)。

(3)  针对任意的输入 x,在加入 en+1 之前,分别计算每一个元素的签长并假定其中最大值为dmaxd1d2dn

(4)  因为新元素 en+1的签长计算只与自身编号和自身权重相关,所以可以使用 x立计算其签长(同时其他元素无须重新计算,假定签长为dn+1

(5)  因为 straw算法需要选出最大签长作为输出,所以:若 dn+1>dmax,那么 x将被重新映射至 en+1上,反之,对 x的已有映射不会产生影响。

由上可见,添加一个元素,straw    算法会随机地将一些原有元素中的数据重新映射至新加的元素之中。同理,删除一个元素,straw    算法会将该元素中的数据全部重新随机映射至其他元素之中。因此无论添加或者删除元素,都不会导致数据在除被添加或者删除之外的两个元素(即不相干的元素)之间进行迁移。这也是 straw算法的设计初衷,即一个元素的 weight调高或者调低,效果作用于该调整了weight的元素以及另外一个特定的相关元素,数据会从另一个元素向它迁入或者从它向另一个元素迁出,而不会影响到集群内其他不相关的元素。

理论上,straw算法是完美的,但随着 Ceph 存储系统应用日益广泛,不断有用户向Ceph社区反馈,每次集群有新的OSD加入、旧的 OSD 删除,或用户仅在一个元素上做很小的权重调节后,就会触发存储集群上很大的数据迁移。这迫使Sagestraw算法重新进行审视。

经代码分析,straw算法的 weight计算会关联一个所有元素共用的 scalingfactor(比例因子,即 Ceph集群中某个元素的权重值调整,都会影响到集群内其他元素的权重值变化。

straw算法实现如下。

max_x = -1

max_item =-1

foreach item:

x = hash(inputr)

x = x* item_strawif x > max_x

max_x = xmax_item= item

returnmax_item

 

由上述算法可知,max_item的输出主要由数据输入(input、随机值(ritem_ straw计算得出,而 item_straw通过权重计算得到,伪代码实现如下。

 


reverse= rearrange all weights in reverse order

straw = -1

weight_diff_prev_total= 0

foreach item:

item_straw= straw* 0x10000

weight_diff_prev=(reverse[current_item]-reverse[prev_item])* item_remainweight_diff_prev_total+= weight_diff_prev

weight_diff_next=(reverse[next_item]-reverse[current_item])* item_remainscale= weigth_diff_prev_total/ (weight_diff_next+ weight_diff_prev)

straw*=pow(1/scale1/item_remain)

 

straw算法中,将所有元素按其权重进行逆序排列后逐个计算每个元素的 item_straw,计算过程中不断累积当前元素与前后元素的权重差值,以此作为计算下一个元素item_straw的基准。因此 straw 算法的最终结果不但取决于每一个元素自身权重,而且也与集合中所有其他元素的权重强相关,从而导致每次加入新的元素或者从集群中剔除元素时都会引起不相干的数据迁移。

Sage 及社区对该问题进行了修复,出于兼容性的考虑,Sage重新设计了一种对原有straw算法进行修正的新算法,称为straw2straw2 在计算每个元素的签长时仅使用自身权重,因此代码可以完美反应Sage的初衷(也因此可以避免不相干的数据迁移,同时计算也变得更加简单,其伪代码如下。

 

max_x = -1

max_item =-1

foreach item:

x = hash(inputr)

x = ln(x/65536) / weight

if x >max_xmax_x=x

max_item = itemreturnmax_item

 

分析 straw2算法可知,straw2算法将 scalingfactor修改为 ln(x/65536) /weight的方式作为代替,针对输入和随机因子执行后,结果落在 [0~65535],因此 x/65536然是小于 1 的值,对其取自然对数[ln(x/655536)]后的结果为负数 1,进一步,将其除以 

自身权重(weight)后,权重越大,其结果越大,从而体现了我们所期望的每个元素权重对于抽签结果的正反馈作用。这个变化使得一个元素权重值的修改不会影响到其他的元素权重,集群内某个元素的权重调整引发的集群数据迁移范围也得到了很好的控制。

简要总结straw算法里面添加节点或者减少节点,其他服务器上的OSD之间会有PG的流动(即数据的迁移);Straw2算法里面添加节点或者减少节点,只会有 PG从变化的节点移出或者从其他点移入,其他不相干节点不会触发数据的迁移。CephLuminous版本开始默认支持 straw2算法。

 

1  CRUSH算法整体是整型运算,新引入的ln()函数是一个浮点运算,为了算法整体效率,当前的实施方法是引入了一128KB的查找表来加速ln()函数的运算速度。


相关文章
|
10天前
|
人工智能 前端开发 编译器
【AI系统】LLVM 架构设计和原理
本文介绍了LLVM的诞生背景及其与GCC的区别,重点阐述了LLVM的架构特点,包括其组件独立性、中间表示(IR)的优势及整体架构。通过Clang+LLVM的实际编译案例,展示了从C代码到可执行文件的全过程,突显了LLVM在编译器领域的创新与优势。
31 3
|
14天前
|
运维 持续交付 云计算
深入解析云计算中的微服务架构:原理、优势与实践
深入解析云计算中的微服务架构:原理、优势与实践
43 1
|
13天前
|
弹性计算 持续交付 API
构建高效后端服务:微服务架构的深度解析与实践
在当今快速发展的软件行业中,构建高效、可扩展且易于维护的后端服务是每个技术团队的追求。本文将深入探讨微服务架构的核心概念、设计原则及其在实际项目中的应用,通过具体案例分析,展示如何利用微服务架构解决传统单体应用面临的挑战,提升系统的灵活性和响应速度。我们将从微服务的拆分策略、通信机制、服务发现、配置管理、以及持续集成/持续部署(CI/CD)等方面进行全面剖析,旨在为读者提供一套实用的微服务实施指南。
|
9天前
|
运维 监控 Java
后端开发中的微服务架构实践与挑战####
在数字化转型加速的今天,微服务架构凭借其高度的灵活性、可扩展性和可维护性,成为众多企业后端系统构建的首选方案。本文深入探讨了微服务架构的核心概念、实施步骤、关键技术考量以及面临的主要挑战,旨在为开发者提供一份实用的实践指南。通过案例分析,揭示微服务在实际项目中的应用效果,并针对常见问题提出解决策略,帮助读者更好地理解和应对微服务架构带来的复杂性与机遇。 ####
|
12天前
|
NoSQL Java 数据处理
基于Redis海量数据场景分布式ID架构实践
【11月更文挑战第30天】在现代分布式系统中,生成全局唯一的ID是一个常见且重要的需求。在微服务架构中,各个服务可能需要生成唯一标识符,如用户ID、订单ID等。传统的自增ID已经无法满足在集群环境下保持唯一性的要求,而分布式ID解决方案能够确保即使在多个实例间也能生成全局唯一的标识符。本文将深入探讨如何利用Redis实现分布式ID生成,并通过Java语言展示多个示例,同时分析每个实践方案的优缺点。
27 8
|
9天前
|
算法 NoSQL Java
微服务架构下的接口限流策略与实践#### 一、
本文旨在探讨微服务架构下,面对高并发请求时如何有效实施接口限流策略,以保障系统稳定性和服务质量。不同于传统的摘要概述,本文将从实际应用场景出发,深入剖析几种主流的限流算法(如令牌桶、漏桶及固定窗口计数器等),通过对比分析它们的优缺点,并结合具体案例,展示如何在Spring Cloud Gateway中集成自定义限流方案,实现动态限流规则调整,为读者提供一套可落地的实践指南。 #### 二、
25 3
|
11天前
|
负载均衡 Java 开发者
深入探索Spring Cloud与Spring Boot:构建微服务架构的实践经验
深入探索Spring Cloud与Spring Boot:构建微服务架构的实践经验
45 5
|
7天前
|
消息中间件 运维 安全
后端开发中的微服务架构实践与挑战####
在数字化转型的浪潮中,微服务架构凭借其高度的灵活性和可扩展性,成为众多企业重构后端系统的首选方案。本文将深入探讨微服务的核心概念、设计原则、关键技术选型及在实际项目实施过程中面临的挑战与解决方案,旨在为开发者提供一套实用的微服务架构落地指南。我们将从理论框架出发,逐步深入至技术细节,最终通过案例分析,揭示如何在复杂业务场景下有效应用微服务,提升系统的整体性能与稳定性。 ####
23 1
|
9天前
|
监控 安全 持续交付
构建高效微服务架构:策略与实践####
在数字化转型的浪潮中,微服务架构凭借其高度解耦、灵活扩展和易于维护的特点,成为现代企业应用开发的首选。本文深入探讨了构建高效微服务架构的关键策略与实战经验,从服务拆分的艺术到通信机制的选择,再到容器化部署与持续集成/持续部署(CI/CD)的实践,旨在为开发者提供一套全面的微服务设计与实现指南。通过具体案例分析,揭示如何避免常见陷阱,优化系统性能,确保系统的高可用性与可扩展性,助力企业在复杂多变的市场环境中保持竞争力。 ####
27 2
|
13天前
|
监控 Serverless 云计算
探索Serverless架构:开发实践与优化策略
本文深入探讨了Serverless架构的核心概念、开发实践及优化策略。Serverless让开发者无需管理服务器即可运行代码,具有成本效益、高可扩展性和提升开发效率等优势。文章还详细介绍了函数设计、安全性、监控及性能和成本优化的最佳实践。