Ceph 分层缓存--Tiering Cache

原文来自Ceph官方文档：CACHE TIERING

部分摘抄自Ceph中国社区翻译文档：分级缓存

1、分层缓存介绍

分层缓存为ceph客户端中的某些存放在存储层的数据提供更好的IO性能。分级缓存需创建一个由高速而昂贵存储设备（如 SSD ）组成的存储池、作为缓存层，以及一个相对低速/廉价设备组成的后端存储池（或纠删码编码的）、作为经济存储层。Ceph 的对象处理器决定往哪里存储对象，分级代理决定何时把缓存内的对象刷回后端存储层；所以缓存层和后端存储层对 Ceph 客户端来说是完全透明的。

Ceph缓存池架构模型

缓存代理层管理着数据在缓存层和存储层之间的自动迁移。但是, 管理员也可以通过配置来干预迁移规则，下面是对两个主要场景的介绍:

Writeback Mode：当管理员将缓存层配置成回写模式, Ceph客户端将数据写入缓存层，并接收返回的ACK。同时，写入缓存层的数据迁移到存储层，然后从缓存层刷掉。直观的看，缓存层在存储层之前。当Ceph客户端需要存在于存储层的数据时，缓存层代理会把这些数据迁移到缓存层，然后再发往 Ceph 客户端。因此，Ceph 客户端将与缓存层进行 I/O 操作，直到数据不再被读写。此模式对于易变数据来说较理想（如照片/视频编辑、事务数据等）。

Read-proxy Mode：这个模式将使用一些已经存在于缓存层的数据，但是，如果数据不在缓存层，请求将被代理转发到底层。这个模式对于从回写模式过渡到禁用缓存非常有用的，因为它润需负载一直工作到缓存干涸，不再向缓存添加任何数据。

2、警告

如果负载过多，分层缓存会降低性能。用户在使用以下特性时需要极其谨慎。

Workload dependent: 缓存是否能提升性能，高度依赖于负载能力。因为将数据移入或移除缓存会导致额外的开销，它只在对数据集的访问有大的偏离时有影响。例如, 众多的请求访问小数量的objects，这时，你的缓存池需要非常大，才能在处理所有请求时，避免数据过渡。

Difficult to benchmark: 用户使用评测性能时，大部分的关于分层缓存bechmarks测试结果，将会是一个糟糕的结果。其中部分原因是很少的bechmarks倾斜于一组小的对象集合的请求，这会使缓存经过很长时间后才能“活跃起来”，并且这种“活跃起来”会导致高昂的开销。

Usually slower: 对于并没有友好使用分级缓存的工作负载，性能普遍低于一个没使用分级缓存的普通rados池。

librados object enumeration: 对于librados级别的枚举对象API并不能连贯存在在这种情况中（The librados-level object enumeration API is not meant to be coherent in the presence of the case）。如果你的应用直接使用rados，并且依赖于枚举对象，分级缓存不能向期待的那样工作. (对于RGW, RBD, or CephFS，没有这个问题)

Complexity: 在使用RADOS集群时，使用分级缓存意味着大量的额外器械和复杂性。这会增加你遇到未知的BUG（可能其他人未遇到过）的可能性，并且使你的部署拥有更大的风险。

已知的成功的负载方式

RGW time-skewed: 如果RGW工作中遇到的大部分操作是朝向最近写入的数据，一个简单的分级缓存可以工作得很好。

已知的错误的负载方式

下面的配置使用分层缓存效果不佳。

RBD with replicated cache and erasure-coded base: 这是一个普遍的需求, 但是通常不能很好工作。即使合理的倾斜工作负载，仍然会遇到一些对于冷门object的写操作的情况，并且由于纠删码类型的池还不支持轻微的读写操作，为了适应一些小的写入操作（通常4kb），整个object块（通常4MB）必须被全部迁移到缓存。只有少数用户成功的应用了这种部署方式，并且这种部署方案只能为他们工作是因为他们的数据是极其“冷门”的（例如备份），并且他们对于性能并不敏感。

RBD with replicated cache and base: 在使用备份类型为基础层时比以纠删码为基础层时，RBD的表现更为良好，但是它在工作负载中仍然依赖于大量的倾斜，并且很难验证。用户需要对他们的工作负载有更好的理解，并且需要仔细调整分层缓存参数。

3、配置存储池

为了建立分层缓存，你必须拥有两个存储池。一个作为后端存储，一个作为缓存。

3.1 配置后端存储池

建立一个后端存储池包含两种场景：

标准存储: 在这种场景中，这个池在Ceph存储集群中存储一个对象的多个副本。

纠删码: 在这种场景中，存储池用纠删码高效地存储数据，性能稍有损失。

在标准存储场景中，你可以用 CRUSH 规则集来标识失败域（如 osd 、主机、机箱、机架、排等）。当规则集所涉及的所有驱动器规格、速度（转速和吞吐量）和类型相同时， OSD 守护进程运行得最优。创建规则集的详情见CRUSH 图。创建好规则集后，再创建后端存储池。

在纠删码编码情景中，创建存储池时指定好参数就会自动生成合适的规则集，详情见创建存储池。

在后续例子中，我们把cold-storage当作后端存储池。