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数据。为了适配这种新的存储介质，RWL（ReplicatedWriteLog）技术被开发出来，下面对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库的位置。

 

图 3-9PMOK架构和应用

 

3.  RWL架构

 

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

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

（1）  客户端对 Image发送写请求；

（2） 每个Image在本地的 persistmemory中，都会有一块独立的空间来存储缓存数据；

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

 

图 3-10RwL架构

 

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

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

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

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

 

 

 

4.  RWL的优点和局限性

 

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

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

3.1.5     QoS

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

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

1.  mClock

 

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

（1）  Constraint-Based 阶段，处理所有预留时间标签满足条件的请求（预留时间标签值小于或等于当前时间）；

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

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

 

 

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

RequestArrival (request r，timet，client 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阶段被处理，无法满足预期的预留效果。

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

 

 

 

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

 

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

2.  dmClock

 

DistributedmClock（即dmClock）算法对mClock算法进行了改进，dmClock是mClock的分布式版本，需要在每个 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。

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

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

图 3-12dmCock-Server队列