带你读《存储漫谈Ceph原理与实践》第三章接入层3.1块存储 RBD(四)-阿里云开发者社区

开发者社区> 人民邮电出版社> 正文
登录阅读全文

带你读《存储漫谈Ceph原理与实践》第三章接入层3.1块存储 RBD(四)

简介: 带你读《存储漫谈Ceph原理与实践》第三章接入层3.1块存储 RBD

3.1.4    RBDCache

 

1.  RBDCache介绍

 

RBDCache在 Ceph 的块存储接口中,用来缓存客户端的数据,它主要提供读缓存和写合并功能,最终提高I/O 读写的性能。需要注意的是,Ceph 既支持以内核模块方式动态地为Linux主机提供块设备(KRBD),也支持以QEMUBlockDriver的形式为VM提供虚拟块设备(QEMU+librbd),本章节描述的是第二种形式。

RBDCache目前在 librbd中主要以 ObjectBufferExtent 为基本单位进行缓存,一个RBD块设备在 librbd层以固定大小分为若干个对象,而读写请求通常会有不同的 I/O尺寸,每个请求的 Buffer大小都会以 Object为单位放到一个或多个 ObjectBufferExtent中。

目前 RBDCache 只支持以内存形式存在,因此需要提供一些策略来不断回写到Ceph集群来实现数据持久化,以防止客户端掉电引起的 RBDCache缓存数据丢失。

在 librbd中有若干选项来控制RBDCache 的大小和回写策略。rbd_cache_size:控制 librbd 能使用的最大缓存大小。rbd_cache_max_dirty:控制缓存中允许脏数据的最大值。

rbd_cache_target_dirty :控制 RBDCache 开始执行回写过程的脏数据水位线,其数值不能超过 rbd_cache_max_dirty大小。

rbd_cache_max_dirty_age   :控制缓存中单个脏数据最大的存在时间,避免脏数据长时间存在。

除了在空间维度和时间维度控制缓存回写逻辑之外,librbd 也提供了flush 接口,该接口同样能够触发缓存中的脏数据回写操作。

因为 RBDCache 是以内存的形式存在,因此会出现下面的问题:

(1)内存作为缓存,缓存空间不能太大;

(2)Kernelcrash 或者主机掉电,很容易造成数据丢失的风险。

为了解决上面的问题,Ceph引入一种非易失存储介质代替内存,持久化 RBDCache数据。为了适配这种新的存储介质,RWLReplicatedWriteLog)技术被开发出来,下面对RWL进行介绍。

2.  RWL使用的 PMDK技术

 

PMDK, 全称 PersistentMemoryDevelopmentKit,它是一套具有 DAX(DirectAccess)访问特性的开发工具库。

NVM(Non-VolatileMemory)存储能够使具备DAX功能的文件系统直接暴露在用户空间,用户态程序可以使用标准的文件系统 API来操作 NVM,同样也可以使用 mmap将其直接映射到用户空间。无论使用哪种方式,对 NVM的操作都会直接转换为对NVM的登录(load和存储(store,中间没有页面缓存(pagecache)(这也是支持DAX模式的文件系统和普通文件系统之间的主要区别)。

在使用文件系统时,数据的完整性一般都由文件系统来保证,而   NVM   作为一种非易失性存储,在使用 mmap 方式来读写时,如何保证数据的完整性和一致性就显得尤为重要。通常有很多种方式可以做到这一点(后文将展开讨论),比如靠上层应用程序自己的策略来保证,也可以使用第三方库来保证,PMDK(更具体点来说是 PMDK中的 libpmemobj)就是用来完成这项工作的。在图 3-9中箭头的位置都是 libpmemobj库的位置。

image.png

 


图 3-9PMOK架构和应用

 

3.  RWL架构

 

图 3-10所示的是 RWL的架构,从图中可以看出,计算节点提供 persistmemory,来存储缓存数据,在存储节点也提供 persistmemory,作为计算节点缓存数据的冗余备份。

RWL 保存缓存数据的过程如下。

(1)  客户端对 Image发送写请求;

(2) 每个Image在本地的 persistmemory中,都会有一块独立的空间来存储缓存数据;

(3) 把客户端的数据和一些控制信息封装成一个结构体,这里称作数据日志,存储在persistmemory中,每写一些数据日志(比如30条数据日志),会增加一条同步日志;

image.png


 

图 3-10RwL架构

 

(4)  与此同时,通过 RDMA技术,把封装的结构体在远端的 persistmemory中再备份,达到容灾的目的。

因为客户端每次的写入数据都优先存储在 persistmemory中,而没有通过 librbd写入 Ceph 存储集群中,所以这些数据会标记为脏数据;RWL会根据一些条件,把这些脏数据写入 Ceph集群,这样 persistmemory就会有空间存储新的客户端数据。

3-1所示是开启RWL和没有开启RWL的测试数据。通过数据可以看出,开启 RWL,IOPS得到了大幅提升。

表3-1    100GB卷空间测试对比

 

 

cache

 

iosize

 

iodepth

rwl

size

rbd_cache_

disable_patch

VM

cache attr

 

IOPS

 

BW

 

Avg-lat

enable

16KB

1

1G

YES

writeback

4960

81.3Mbit/s

3041.43µs

disable

16KB

1

N/A

YES

none

323

5292Kbit/s

6306.72µs

 

 

4.  RWL的优点和局限性

 

RWL 可以提高数据的读写性能,满足用户对高性能的要求,即使服务器掉电,数据也不会丢失,为用户提供了较高的数据高可用性。

RWL必须使用 persistmemory 存储设备,普通的存储设备无法满足其使用要求,目前这种 persistmemory 设备仍然相当昂贵,用户需要综合考虑该方案的性价比。


3.1.5     QoS

QoSQualityofService)是一种控制机制,它提供了针对不同用户或不同数据流采用不同优先级的 I/O 读写能力服务策略,可根据程序的要求,保证数据流的性能达到一定的水准。

在存储领域,QoS 主要表现为对存储访问的IOPS或者带宽(Bandwith)控制,一个优秀的 QoS算法要求能够满足每个Client的最低请求处理需求,同时也保证 I/O服务能力不超过预设值限制,且能够根据优先级不同,分配不同的权重资源,mClock 就是这样的算法。令牌桶也能够实现一定的QoS上限能力限制,但因其无法保证 QoS 下限,本小节不做展开介绍。

1.  mClock

 

mClock是基于时间标签的 I/O 调度算法,适用于集中式管理的存储系统。mClock使用Reservation、Limit及 Proportion作为 QoSSpec。Client端提供(rlw参数值,Server端根据这3个参数计算时间标签计算公式见式3-1、式3-2、式3-3,式中运算符号含义说明见表3-2,并分为两个阶段处理I/O请求。

(1)  Constraint-Based 阶段,处理所有预留时间标签满足条件的请求(预留时间标签值小于或等于当前时间);

(2)  Weight-Based阶段,处理上限时间标签满足条件的请求,若有多个Client同时满足条件,则依据权重时间标签的大小决定处理顺序(即权重时间标签较小的 Client的请求优先被处理)。

image.png

image.png

表3-2 运算符号含义说明

 

符号

含义

Rr

i

表示Client i 的第r 个请求的预留时间标签 1

Lr

i

表示Client i 的第r 个请求的上限时间标签

Pr

i

表示Client i 的第r 个请求的权重时间标签

ri

表示Client i 的预留值

li

表示Client i 的上限值

wi

表示Client i 的权重

 

mClock 算法的伪代码如下所示。

RequestArrival (request rtimetclient Ci)begin

if Ci was idle then

minPtag = minimum of all Ptags

foreachactive Cj do

Pj-= minPtag-t

end

R<i, r> = max{R<i, r-1> + 1/r<i>, t}L<i, r> = max{L<i, r-1> + 1/l<i>, t}P<i, r> = max{P<i, r-1> + 1/w<i>, t}ScheduleRequest()

ScheduleRequest ()begin

Let E bethe setof requestswith Rtag <=t

if E not empty then

select IO request withminimum R tagfrom Eelse

Let E' bethe setof requestswith Ltag <= t

if E' not empty then

select IO request with minimum P tag fromE'

/*Assuming request belong to clientc<k>*/Subtract 1/r<k> from R tags of C<k>

end

mClock-Server动态地工作在 Constraint-Based和 Weight-Based阶段,为了减少Client之间的竞争,它总是期望请求在Constraint-Based阶段被处理。当某个 Client的请求在 Weight-Based 阶段被处理,该 Client子队列剩余请求的预留时间标签都要减去 1/r, 保留该Client预留时间标签的正确性,调整过程如图3-11所示,若不对剩余请求的预留时间标签进行处理,则第三个请求的初始的预留时间标签t+3/r更难以满足 Constraint-Based阶段被处理的条件,从而使得该Client的I/O请求一直在Weight-Based阶段被处理,无法满足预期的预留效果。

1Clienti第一个到达的请求的时间设为t(t= currenttime)。

 

 image.png


 

图 3-11请求在 weght-Based 阶段被处理时预留时间标签调整过程

 

mClock存在一定的局限性, 即 mClock的应用场景为多个 Client向同一个 Server端发送请求,但是对于分布式存储系统,需要多个 Client端向多个 Server端发送请求,mClock算法在此类场景不再适用。

2.  dmClock

 

DistributedmClockdmClock算法对mClock算法进行了改进,dmClockmClock的分布式版本,需要在每个 Server上都运行一个mClock服务端,将 QoSSpec分到不同的Server共同完成。

dmClock算法与 mClock 算法之间的差异如下。

(1)  分布式系统中的各个 Server向 Client 返回的响应结果中包含其请求在哪个阶段被处理;

(2)  Client会统计各个 Server所完成请求的个数,在向某一 Server发送请求时,请求中会携带自上次给该 Server 下发的请求之后,其他 Server完成的请求个数之和,分别用ρδ表示两个阶段的增量;

(3) Server在计算请求时间标签时,不再根据步长(1/r,1/w,1/l)等长递增,而使用ρδ调整因子,使得总的处理速度满足QoS约束条件。

请求的时间标签计算公式见式3-4、式3-5、式3-6。

image.png

如前面所讲,dmClock也是由 Client和 Server两部分组成,其中 Client的主要功能

是统计每个 Server分别在两个阶段完成请求的个数,以此来调整 Server处理请求的速率。Server部分是算法的核心,每个Server 中的dmClock-Server 队列由一个两级映射队列组成,如图 3-12所示,一级是由各个 Client组成的 Clientqueue,另一级是 Client对应的请求子队列 requestqueue

image.png

图 3-12dmCock-Server队列

 


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
最新文章
相关文章
官网链接