《ceph的数据存储》由会员分享，可在线阅读，更多相关《ceph的数据存储（54页珍藏版）》请在金锄头文库上搜索。
1、ceph 的数据存储之路(12)cache tier对于 cache 的东西啊，我曾经在公司的项目中，有写过 cache 的经历，所以我以为我很了解，在我看 ceph 手册对 于 cache tier 描述的时候，感觉没啥新鲜的东西，但是当我 对应到 ceph 源码级别的时候，发现自己 YY 的 ceph cache tier 不太正确。了解不难，深入不易啊。闲话少说进入正题。 （排版有点乱）一、什么是 cache tier 在 ceph 的手册里 http:/ -tiering/ 中对 cache tiering 进行了描述。分布式的集群一般都是采用廉价的pc搭建，这些pc通常使 用的是传统
2、的机械硬盘，所以在磁盘的访问速度上有一定的 限制，没有理想的iops数据。当去优化一个系统的10性能 时 最先想到的就是添加cache热数据在cache被访问到， 缩短数据的访问延时。 Cache 一般会有 memory 或者 ssd 来做考虑到价格和安全性一般都是采用ssd作为cache。 尤其实在随机io上，如果随机io全部放在ssd上，等数据 冷却，将数据合并后，再刷入机械硬盘中，提升系统的io性 能。（本来是想给大家看一下 ssd 和机械盘的性能测试结果的， 但是测试数据是公司的不能放出来，自己测试的数据找不到 了。）。对于 ceph 而言，怎么利用 ssd 作为普通磁盘的 cache
3、 的， 从手册中可知，先创建一个机械硬盘的pool，叫做storage tier ,然后再创建一使用ssd的pool ,叫做cache tier , 把 cache tier 放在 storage tier 之上。如下图：当客户端访问操作数据时，优先读写cache tier数据（当然要 根据cache mode来决定），如果数据在storage tier则会提 升到 cache tier 中，在 cache tier 中 会有请求命中算法、缓 存刷写算法、缓存淘汰算法等的实现，将热数据提升到 cache tier 中，将冷数据下放到 storage tier 中。这就是一般的缓存技术实现，但是
4、对于 ceph 来讲一个分布 式的存储怎么来实现这个cache tier，实现起来是不是和文 档一样的呢？让我们一起来探秘 cache tier.二、Cache tier 基本了解1、cache tier是基于pool的。这里值得注意的是cache pool 对应storage pool，不是ssd磁盘对应机械硬盘的，所以在 cache tier 和 storage tier 之间移动数据 是两个 pool 之间数 据的移动，数据可能在不同地点的设备上移动。2、cache mode 有四种：writeback、forward、readonly、 readforward、 readproxy 模
5、式，这里每种模式都来解释下： -a、writeback 模式:写操作，当请求到达 cache 成，完成 写操作后，直接返回给客户端应答。后面由 cache 的 agent 线程负责将数据写入 storage tier 。读操作看是否命中缓存， 如果命中直接在缓存读，没有命中可以 redirect 到 storage tier 访问。-b、forward 模式：所有的请求都 redirct 到 storage tier 访 问。-creadonly模式 写请求直接 redirct到 storage tier访问， 读请求命中则直接处理，没有命中需要提升storage tier到 cache ti
6、er中，完成请求，下次再读取直接命中缓存。-d、 readforward 模式：读请求都 redirect 到 storage tier 中，写请求采用 writeback 模式。-e、 readproxy 模式：读请求发送给 cache tier， cache tier 去base pool中读取，在cache tier获得object后，自己不 保存，直接发送给客户端，写请求采用 writeback 模式。3r cache的flush、evict算法，都是根据时间先后来的。这 里有一些值得去改进的地方。4r cache的agent是应该根据pg的情况来实现，和pg的 恢复流程一样，一个是r
7、ecovery，个是agent，但是最终 放在了 osd实现。三、ceph cache tier 处理流程：还是原来的配方，正宗好凉cha。说一大堆理论，也不如 从代码入手，那我们就先从代码的流程来讲讲 cache tier， 然后再分析 cache tier 的问题，最后觉得哪里可以完善的， 希望和大家进行讨论。手册里 已经教会大家怎么来使用这个 cache tier 的，不知道 的自行回去修习，不然怕后面看不懂，那这里再手把手走一 下？我用的是实验环境，也没有ssd盘，直接在普通盘上创建一 个cachepool，我们只是看一下cache tier的处理流程，所 以影响不大。1.1ceph
8、实验环境，可参考 https:/ mon， 3 个 osd。1.2 创建 cache pool ，这里为了方便跟踪代码，所以创建的 cachepool 只有 8 个 pg。这里原本有一个 rbd pool 是创建 ceph 默认，然后再新创建 个cache tier的pool新的pool名字直接叫做cachepoolo 现在我们有两个pool 一个是rbd，一个cachepool。1.3添加cachepool为rbd的tier这里直接使用add-cache 命令，该命令是其他几个命令集合的形式，用起来快速一点， 采用默认项。但是后面要接一个缓存大小的设置，这里使用200M 的大小。./ceph
9、 osd tier add-cache rbd cachepool 209715200 然后查看 pool 的详细信息Pool 0就是名字为rbd的pool，这里有两个重要指标 read_tier 1 write_tier 1,这里的 1指的是 pool 1. Pool 1 就是 刚刚创建的cachepool，在看看pooll的设置，tier_of为0 是指pooll是poolO的tier，还有一个重要的要说 cache_mode，默认创建的就是write_back模式的缓存，最 后一个 bloom 过滤器，缓存命中的算法，忘了是什么的人， 可以搜一下。代码里去搜一下add-cache的实现就
10、可以知道了，命令会发 送给 osdminitor，在 osd minitor 中处理。前面一些对pool的检查代码就不说了，这里是主要的代码， 这部分代码比较简单可以一代而过就好了。总之就是将 tier 的关系添加到两个pool里，然后pool的信息会推送到所有 的节点上。6496：获取 base pool 信息 6497：获取 cache pool 信息 6498：检查是 pool tier 的关系。6502：将 cache pool 添加到 base pool 的 tiers 集合中。6503：将 base pool 的 read_tier write_tier 都设置为cachepool
11、。这个很有用。6506：设置 cache pool 的缓存模式，默认为 write_back， 可以手动设置其他模式。65076511：就是和缓存 flush、evict 相关的参数了。后面 的讲flush和evict的时候会分析具体的参数。到这里 已经设置好了 base pool 和 cache pool 的 tier 关系 了。那么就存在一个问题了，客户端要写一个object，这个 object肯定是指向base pool的，怎么将object先写入到 cache pool 的？1.4 测试读写请求，看请求如何从 base pool 转向到 cache pool。测试 代码，创建一个myi
12、mage的rbd，然后向rbd写入数 据。rootcephmon:/ceph/ceph-0.94.2/src#cat ./python/create_rbd.py#!/usr/bin/env pythonimport sys,rados,rbddef connectceph():cluster = rados.Rados(conffile =/root/ceph/ceph-0.94.2/src/ceph.conf) cluster.connect()ioctx = cluster.open_ioctx(rbd) rbd_inst = rbd.RBD() size = 1*1024*3 #4 G
13、iB rbd_inst.create(ioctx,myimage,size) image = rbd.Image(ioctx,myimage) data = foo* 200 image.write(data,0) image.close() ioctx.close() cluster.shutdown()if _name_ = _main_:connectceph() rootcephmon:/ceph/ceph-0.94.2/src#客户端的调用流程就不细说了，前面的blog也有讲过，这里 我们挑重点的说。在客户端想ceph集群发送写请求的时候， 一定会先拿到 pool 的相关信息，然后根
14、据 pool 的信息再经 过 crush 算法，得知数据副本所在的位置，然后把数据发送 到对应的osd上。这里比较重要的就是计算crush算法，因 为 crush 算法会决定你发送到那些 osd 上。跟踪 客户端代码：/src/osdc/Objecter.cc中 Objecter:_calc_target，捡重要的说，2513：判断是否需要检查 存在 cache tiering。2516 :如果是读请求，并且该pool存在read_tier。这个 read_tier就是上面说的在osd monitor设置过的指向cache pool。25仃:如果是读请求则将target_oloc.pool设置
15、为read_tier。 2519 :判断是写请求，并且该pool存在write_tier。这个值 也是在 osd minitor 中设置过的的，指向 cache pool。 2518:如果是写请求，则将 target_oloc.pool 设置为 write_tier。这里重要的是设置了 target_oloc.pool，本来这个值是指向 base pool 的，但是由于设置了 add-cache 命令，这里 target_oloc.pool 指向了 cache pool。当相面使用 target 进行 crush 计算的时候，就能计算出 cache pool 中对应的 object 存储的osd。将请求发送到对应osd上。1.5 cache pool 的请求处理。决定请求是否缓存命中，或者 redirect 处理。osd 先接收到客户端发送来的请求，然后调用 ReplicatedPG: do_request（） >>>>> ReplicatedPG:do_op （） 中处理，这都是正常的一个 pool 处理请求的流程，在 do_op 中来看看不同于其他普通 pool 的处理。当然也在里面挑重要的说：1623：判断下，当在对应的 object
